На прошлой неделе мы рассказали о новых возможностях обновленной версии платформы VMware vSphere 8 Update 1, а также новых функциях инфраструктуры хранилищ (Core Storage). Сегодня мы поговорим о новой версии vSAN 8 Update 1 - решения для организации отказоустойчивых кластеров хранилищ для виртуальных машин.
В vSAN 8 компания VMware представила архитектуру хранилища vSAN Express Storage Architecture (ESA), сделав весомый вклад в развитие гиперконвергентной инфраструктуры. В первом пакете обновлений vSAN компания VMware продолжает развивать этот продукт, позволяя клиентам использовать современные массивы, которые обеспечивают новый уровень производительности, масштабируемости, надежности и простоты использования.
Обзор основных возможностей vSAN 8 Update 1 вы также можете увидеть в видео ниже (откроется в новом окне):
В vSAN 8 Update 1 продолжают разрабатывать и улучшать обе архитектуры - vSAN OSA и vSAN ESA. Давайте посмотрим, что нового появилось в vSAN U1:
1. Масштабирование распределенных хранилищ
Обработка разделенных ресурсов вычисления и хранения в кластерах улучшена в версии vSAN 8 U1. Клиенты могут масштабироваться новыми способами, совместно используя хранилища данных vSAN с другими кластерами vSAN или только с вычислительными кластерами vSphere в рамках подхода HCI Mesh.
Управление распределенными хранилищами HCI Mesh с помощью архитектуры Express Storage
В vSAN 8 U1 архитектура Express Storage Architecture (ESA) позволяет клиентам максимизировать использование ресурсов устройств нового поколения путем предоставления общего доступа к хранилищами в нескольких нерастянутых кластерах для подхода HCI Mesh. Пользователи могут монтировать удаленные хранилища данных vSAN, расположенные в других кластерах vSAN, и использовать кластер vSAN ESA в качестве внешнего хранилища ресурсов для кластера vSphere.
Использование внешнего хранилища с помощью растянутых кластеров vSAN для OSA
В vSAN 8 U1 появилась поддержка распределенных хранилищ HCI Mesh при использовании растянутых кластеров vSAN на основе архитектуры хранения vSAN OSA. Теперь пользователи могут масштабировать хранение и вычислительные мощности независимо - в стандартных и растянутых кластерах.
Потребление емкостей хранилищ vSAN для разных экземпляров vCenter Server
vSAN 8 U1 также поддерживает распределенные хранилища в разных средах с использованием нескольких серверов vCenter при использовании традиционной архитектуры хранения (OSA).
2. Улучшение платформы
Улучшенная производительность с использованием нового адаптивного пути записи
В новом релизе представлен новый адаптивный путь записи, который позволяет рабочим нагрузкам с множеством записей и частопоследовательными записями записывать данные оптимальным способом. Улучшенная потоковая запись на ESA обеспечит увеличение пропускной способности на 25% и снижение задержки для последовательных записей. Это обновление не только повлияет на приложения с преобладающим профилем последовательной записи I/O, но и расширит разнообразие нагрузок, которые работают оптимальным образом на ESA vSAN.
Улучшенная производительность для отдельных нагрузок
Чтобы извлечь максимальную пользу из современного оборудования NVMe, в vSAN ESA 8 U1 была оптимизирована обработка I/O для каждого объекта, находящегося на хранилище данных vSAN ESA, повысив производительность на каждый VMDK на 25%. Эти улучшения производительности для отдельных объектов на ESA будут очень эффективны на критически важных виртуальных машинах, включая приложения, такие как реляционные базы данных и нагрузки OLTP.
Улучшенная надежность во время сценариев режима обслуживания.
В vSAN 8 U1 для ESA была добавлена еще одна функция, которая присутствует в vSAN OSA: поддержка RAID 5 и RAID 6 erasure coding с функциями дополнительной защиты от потери данных во время плановых операций обслуживания. Эта новая возможность гарантирует, что данные на ESA хранятся с избыточностью в случае неожиданного сбоя хоста в кластере во время режима обслуживания.
Улучшения управления датасторами
В vSAN 8 U1 администраторы смогут настраивать размер объектов пространства имен, что позволит им более просто хранить файлы ISO и библиотеки контента.
3. Упрощение управления
При использовании управления хранилищем на основе политик (SPBM), клиенты могут определять возможности хранения с помощью политик и применять их на уровне виртуальных машин. vSAN 8 U1 есть несколько новых улучшений, которые упрощают ежедневные операции администраторов, а также добавляют несколько новых возможностей, чтобы помочь глобальной команде поддержки VMware (GS) быстрее решать проблемы клиентов.
Автоматическое управление политиками для Default Storage Policies
(ESA)
В vSAN ESA 8 U1 появилась новая, необязательная кластерная политика хранения по умолчанию, которая поможет администраторам работать с кластерами ESA с оптимальной надежностью и эффективностью. В конфигурации на уровне кластера доступен новый переключатель "Auto-Policy Management". При включении этой функции кластера будет создана и назначена эффективная политика хранения по умолчанию на основе размера и типа кластера.
Skyline Health Score и исправление конфигурации
В vSAN 8 U1 модуль Skyline UX был переработан и теперь содержит новую панель управления состоянием с упрощенным видом "здоровья" каждого кластера. Новый пользовательский интерфейс поможет ответить на вопросы: "Находится ли мой кластер и обрабатываемые им нагрузки в работоспособном и здоровом состоянии?" и "Насколько серьезно это состояние? Следует ли решить эту проблему?".
С таким четким пониманием потенциальных проблем и действий для их устранения вы можете сократить среднее время до устранения проблем (mean time to resolution, MTTR).
Более высокий уровень детализации для улучшенного анализа производительности
Доступный как в Express Storage Architecture, так и в Original Storage Architecture, сервис производительности vSAN 8 U1 теперь включает мониторинг производительности почти в реальном времени, который собирает и отображает показатели производительности каждые 30 секунд.
Упрощенный сбор диагностической информации о производительности
В vSAN 8 U1 в I/O Trip Analyzer для виртуальных машин появился новый механизм планировщика. Вы можете запускать диагностику программно, что позволяет собирать больше и лучших данных, что может быть критически важно для выявления временных проблем производительности. Это улучшение идеально подходит для сред, где ВМ имеет повторяющуюся (хоть и кратковременную) проблему с производительностью.
Новая интеграция PowerCLI
В vSAN 8 U1 PowerCLI поддерживает множество новых возможностей как для архитектур ESA (Express Storage Architecture), так и OSA (Original Storage Architecture). С помощью этих интеграций клиенты ESA получат простой доступ к своему инвентарю для мониторинга и автоматизации управления своей средой и выделением ресурсов.
4. Функции Cloud Native Storage
Выделенные окружения DevOps увеличивают сложность всего центра обработки данных и увеличивают затраты. Используя существующую среду vSphere для хостинга рабочих нагрузок Kubernetes DevOps, клиенты дополнительно увеличивают ценность и ROI платформы VMware. VMware продолжает фокусироваться на потребностях разработчиков: в vSAN 8 U1 были реализованы новые улучшения производительности, простоты и гибкости для разработчиков, которые используют среду, и для администраторов, ответственных за саму платформу.
Поддержка CNS для vSAN ESA
В vSAN 8 U1 мы добавили поддержку Cloud Native Storage (CNS) для vSAN ESA. Клиенты могут получить преимущества производительности vSAN ESA для своих сред DevOps.
Поддержка DPp общих виртуальных коммутаторов
vSAN 8 U1 снижает стоимость и сложность инфраструктуры за счет того, что решения DPp (Data Persistence) теперь совместимы с VMware vSphere Distributed Switch. Клиентам нужны только лицензии vSphere+/vSAN+, чтобы использовать платформу Data Persistence — на vSAN OSA или ESA — и запускать приложения, что дает более низкую общую стоимость владения и упрощение операций.
Развертывние Thick provisioning для vSAN Direct Configuration
Наконец, в vSAN 8 U1 были доработаны кластеры, работающие в конфигурации vSAN Direct Configuration — это уникальная кластерная конфигурация, настроенная под Cloud Native Workloads. С vSAN 8 U1 постоянные тома могут быть программно выделены разработчиком как "thick" (это определяется в классе хранения).
Более подробно о новых возможностях VMware vSAN 8 Update 1 можно почитать на специальной странице.
Недавно мы писали об анонсированных новых возможностях обновленной платформы виртуализации VMware vSphere 8 Update 1, выход которой ожидается в ближайшее время. Параллельно с этим компания VMware объявила и о выпуске новой версии решения VMware vSAN 8 Update 1, предназначенного для создания высокопроизводительных отказоустойчивых хранилищ для виртуальных машин, а также об улучшениях подсистемы хранения Core Storage в обеих платформах.
Недавно компания VMware также выпустила большую техническую статью "What's New with vSphere 8 Core Storage", в которой детально рассмотрены все основные новые функции хранилищ, с которыми работают платформы vSphere и vSAN. Мы решили перевести ее с помощью ChatGPT и дальше немного поправить вручную. Давайте посмотрим, что из этого вышло :)
Итак что нового в части Core Storage платформы vSphere 8 Update 1
Одно из главных улучшений - это новая система управления сертификатами. Она упрощает возможность регистрации нескольких vCenter в одном VASA-провайдере. Это положит основу для некоторых будущих возможностей, таких как vVols vMSC. Такж есть и функции, которые касаются масштабируемости и производительности. Поскольку vVols могут масштабироваться гораздо лучше, чем традиционное хранилище, VMware улучшила подсистему хранения, чтобы тома vVols работали на больших масштабах.
1. Развертывание нескольких vCenter для VASA-провайдера без использования самоподписанных сертификатов
Новая спецификация VASA 5 была разработана для улучшения управления сертификатами vVols, что позволяет использовать самоподписанные сертификаты для многовендорных развертываний vCenter. Это решение также решает проблему управления сертификатами в случае, когда независимые развертывания vCenter, работающие с различными механизмами управления сертификатами, работают вместе. Например, один vCenter может использовать сторонний CA, а другой vCenter может использовать сертификат, подписанный VMCA. Такой тип развертывания может быть использован для общего развертывания VASA-провайдера. Эта новая возможность использует механизм Server Name Indication (SNI).
SNI - это расширение протокола Transport Layer Security (TLS), с помощью которого клиент указывает, какое имя хоста он пытается использовать в начале процесса handshake. Это позволяет серверу показывать несколько сертификатов на одном IP-адресе и TCP-порту. Следовательно, это позволяет обслуживать несколько безопасных (HTTPS) веб-сайтов (или других служб через TLS) с одним и тем же IP-адресом, не требуя, чтобы все эти сайты использовали один и тот же сертификат. Это является концептуальным эквивалентом виртуального хостинга на основе имени HTTP/1.1, но только для HTTPS. Также теперь прокси может перенаправлять трафик клиентов на правильный сервер во время хэндшейка TLS/SSL.
2. Новая спецификация vVols VASA 5.0 и некоторые детали функций
Некоторые новые функции, добавленные в vSphere 8 U1:
Изоляция контейнеров - работает по-разному для поставщиков VASA от различных производителей. Она позволяет выполнять настройку политики контроля доступа на уровне каждого vCenter, а также дает возможность перемещения контейнеров между выбранными vCenter. Это дает лучшую изоляцию на уровне контейнеров, а VASA Provider может управлять правами доступа для контейнера на уровне каждого vCenter.
Аптайм - поддержка оповещений об изменении сертификата в рамках рабочего процесса VASA 5.0, который позволяет обновлять сертификат VMCA в системах с несколькими vCenter. Недействительный или истекший сертификат вызывает простой, также возможно возникновение простоя при попытке регистрации нескольких vCenter с одним VASA Provider. В конфигурации с несколькими vCenter сертификаты теперь можно обновлять без простоя.
Улучшенная безопасность для общих сред - эта функция работает по-разному для поставщиков VASA от производителей. Все операции могут быть аутентифицированы в контексте vCenter, и каждый vCenter имеет свой список контроля доступа (ACL). Теперь нет самоподписанных сертификатов в доверенном хранилище. VASA Provider может использоваться в облачной среде, и для этого также есть доступная роль в VASA 5.0.
Обратная совместимость - сервер ESXi, который поддерживает VASA 5.0, может решать проблемы с самоподписанными сертификатами и простоями, возникающими в случае проблем. VASA 5.0 остается обратно совместимым и дает возможность контролировать обновление в соответствии с требованиями безопасности. VASA 5.0 может сосуществовать с более ранними версиями, если производитель поддерживает эту опцию.
Гетерогенная конфигурация сертификатов - работает по-разному для поставщиков VASA от производителей. Теперь используется только подписанный сертификат VMCA, дополнительный CA не требуется. Это позволяет изолировать доверенный домен vSphere. VASA 5.0 позволяет использовать разные конфигурации для каждого vCenter (например, Self-Managed 3rd Party CA Signed Certificate и VMCA managed Certificate).
Не необходимости вмешательства администратора - поддержка многократного развертывания vCenter с использованием VMCA, которая не требует от пользователя установки и управления сертификатами для VP. Служба SMS будет отвечать за предоставление сертификатов. Теперь это работает в режиме Plug and Play с автоматической предоставлением сертификатов, без вмешательства пользователя, при этом не требуется никаких ручных действий для использования VASA Provider с любым vCenter.
Комплаенс безопасности - отсутствие самоподписанных сертификатов в доверенных корневых центрах сертификации позволяет решить проблемы соответствия требованиям безопасности. Не-СА сертификаты больше не являются частью хранилища доверенных сертификатов vSphere. VASA 5.0 требует от VASA Provider использовать сертификат, подписанный СА для связи с VASA.
3. Перенос Sidecar vVols в config-vvol вместо другого объекта vVol
Sidecars vVols работали как объекты vVol, что приводило к накладным расходам на операции VASA, такие как bind/unbind. Решения, такие как First Class Disks (FCD), создают большое количество маленьких sidecars, что может ухудшить производительность vVols. Кроме того, поскольку может быть создано множество sidecars, это может учитываться в общем количестве объектов vVol, поддерживаемых на массиве хранения. Чтобы улучшить производительность и масштабируемость, теперь они обрабатываются как файлы на томе config-vvol, где могут выполняться обычные операции с файлами. Не забывайте, что в vSphere 8 был обновлен способ байндига config-vvol. В результате, с новым механизмом config-vvol уменьшается число операций и задержки, что улучшает производительность и масштабируемость.
Для этой функциональности в этом релизе есть несколько ограничений при создании ВМ. Старые виртуальные машины могут работать в новом формате на обновленных до U1 хостах, но сам новый формат не будет работать на старых ESXi. То есть новые созданные ВМ и виртуальные диски не будут поддерживаться на хостах ниже версии ESXi 8 U1.
5. Улучшения Config-vvol, поддержка VMFS6 config-vvol с SCSI vVols (вместо VMFS5)
Ранее Config-vvol, который выступает в качестве каталога для хранилища данных vVols и содержимого VM home, был ограничен размером 4 ГБ. Это не давало возможности использования папок с хранилищем данных vVols в качестве репозиториев ВМ и других объектов. Для преодоления этого ограничения Config-vvol теперь создается как тонкий объект объемом 255 ГБ. Кроме того, вместо VMFS-5 для этих объектов будет использоваться формат VMFS-6. Это позволит размещать файлы sidecar, другие файлы VM и библиотеки контента в Config-vvol.
На изображении ниже показаны Config-vvol разных размеров. Для машины Win10-5 Config-vvol использует исходный формат 4 ГБ, а ВМ Win10-vVol-8u1 использует новый формат Config-vvol объемом 255 ГБ.
6. Добавлена поддержка NVMe-TCP для vVols
В vSphere 8 была добавлена поддержка NVMe-FC для vVols. В vSphere 8 U1 также расширена поддержка NVMe-TCP, что обеспечивает совместное использование NVMeoF и vVols. См. статью vVols with NVMe - A Perfect Match | VMware.
7. Улучшения NVMeoF, PSA, HPP
Инфраструктура поддержки NVMe end-to-end:
Расширение возможностей NVMe дает возможность поддержки полного стека NVMe без какой-либо трансляции команд SCSI в NVMe на любом уровне ESXi. Еще одной важной задачей при поддержке end-to-end NVMe является возможность контроля multipath-плагинов сторонних производителей для управления массивами NVMe.
Теперь с поддержкой GOS протокол NVMe может использоваться для всего пути - от GOS до конечного таргета.
Важным аспектом реализации VMware трансляции хранилищ виртуальных машин является поддержка полной обратной совместимости. VMware реализовала такой механизм, что при любом сочетании виртуальных машин, использующих SCSI или контроллер vNVMe, и целевого устройства, являющегося SCSI или NVMe, можно транслировать путь в стеке хранения. Это дизайн, который позволяет клиентам переходить между SCSI- и NVMe-хранилищами без необходимости изменения контроллера хранилищ для виртуальной машины. Аналогично, если виртуальная машина имеет контроллер SCSI или vNVMe, он будет работать как на SCSI-, так и на NVMeoF-хранилищах.
Упрощенная диаграмма стека хранения выглядит так:
Для получения дополнительной информации о NVMeoF для vSphere, обратитесь к странице ресурсов NVMeoF.
8. Увеличение максимального количества путей для пространств имен NVMe-oF с 8 до 32
Увеличение количества путей улучшает масштабирование в окружениях с несколькими путями к пространствам имен NVMe. Это необходимо в случаях, когда хосты имеют несколько портов и модуль имеет несколько нод, а также несколько портов на одной ноде.
9. Увеличение максимального количества кластеров WSFC на один хост ESXi с 3 до 16
Это позволяет уменьшить количество лицензий Microsoft WSFC, необходимых для увеличения количества кластеров, которые могут работать на одном хосте.
Для получения дополнительной информации о работе Microsoft WSFC на vSphere можно обратиться к следующим ресурсам:
10. Улучшения VMFS - расширенная поддержка XCOPY для копирования содержимого датасторов между различными массивами
ESXi теперь поддерживает расширенные функции XCOPY, что оптимизирует копирование данных между датасторами разных массивов. Это поможет клиентам передать обработку рабочих нагрузок на сторону хранилища. Функция уже доступна в vSphere 8 U1, но по факту миграция данных между массивами должна поддерживаться на стороне хранилища.
11. Реализация NFSv3 vmkPortBinding
Данная функция позволяет привязать соединение NFS для тома к конкретному vmkernel. Это помогает обеспечить безопасность, направляя трафик NFS по выделенной подсети/VLAN, и гарантирует, что трафик NFS не будет использовать mgmt-интерфейс или другие интерфейсы vmkernel.
Предыдущие монтирования NFS не содержат этих значений, хранящихся в config store. Во время обновления, при чтении конфигурации из конфигурационного хранилища, значения vmknic и bindTovmnic, если они есть, будут считаны. Поэтому обновления с предыдущих версий не будут содержать этих значений, так как они являются необязательными.
Изменения в способе создания/удаления Swap-файлов для томов vVols помогли улучшить производительность включения/выключения, а также производительность vMotion и svMotion.
13. Улучшения Config vVol и сохранение привязки
Здесь были сделаны следующие доработки:
Уменьшено время запроса при получении информации о ВМ
Добавлено кэширование атрибутов vVol - размер, имя и прочих
Конфигурационный vVol - это место, где хранятся домашние файлы виртуальной машины (vmx, nvram, logs и т. д.) и к нему обычно обращаются только при загрузке или изменении настроек виртуальной машины.
Ранее использовалась так называемая "ленивая отмена связи" (lazy unbind), и происходил unbind конфигурационного vVol, когда он не использовался. В некоторых случаях приложения все же периодически обращались к конфигурационному vVol, что требовало новой операции привязки. Теперь эта связь сохраняется, что уменьшает задержку при доступе к домашним данным виртуальной машины.
14. Поддержка NVMeoF для vVols
vVols были основным направлением развития функциональности хранилищ VMware в последние несколько версий, и для vSphere 8.0 это не исключение. Самое большое обновление в ядре хранения vSphere 8.0 - добавление поддержки vVols в NVMeoF. Изначально поддерживается только FC, но со временем будут работать и другие протоколы, провалидированные и поддерживаемые с помощью vSphere NVMeoF. Теперь есть новая спецификация vVols и VASA/VC-фреймворка - VASA 4.0/vVols 3.0.
Причина добавления поддержки vVols в NVMeoF в том, что многие производители массивов, а также отрасль в целом, переходят на использование или, по крайней мере, добавление поддержки NVMeoF для повышения производительности и пропускной способности. Вследствие этого VMware гарантирует, что технология vVols остается поддерживаемой для последних моделей хранилищ.
Еще одним преимуществом NVMeoF vVols является настройка. При развертывании после регистрации VASA фоновая установка завершается автоматически, вам нужно только создать датастор. Виртуальные эндпоинты (vPE) и соединения управляются со стороны VASA, что упрощает настройку.
Некоторые технические детали этой реализации:
ANA Group (Асимметричный доступ к пространству имен)
С NVMeoF реализация vVols немного отличается. С традиционными SCSI vVols хранилищами контейнер является логической группировкой самих объектов vVol. С NVMeoF это варьируется в зависимости от того, как поставщик массива реализует функциональность. В общем и целом, на хранилище группа ANA является группировкой пространств имен vVol. Массив определяет количество групп ANA, каждая из которых имеет уникальный ANAGRPID в подсистеме NVM. Пространства имен выделяются и активны только по запросу BIND к провайдеру VASA (VP). Пространства имен также добавляются в группу ANA при запросе BIND к VP. Пространство имен остается выделенным/активным до тех пор, пока последний хост не отвяжет vVol.
vPE (virtual Protocol Endpoint)
Для традиционных vVols на базе SCSI, protocol endpoint (PE) - это физический LUN или том на массиве, который отображается в появляется в разделе устройств хранения на хостах. С NVMeoF больше нет физического PE, PE теперь является логическим объектом, представлением группы ANA, в которой находятся vVols. Фактически, до тех пор, пока ВМ не запущена, vPE не существует. Массив определяет количество групп ANA, каждая из которых имеет уникальный ANAGRPID в подсистеме NVM. Как только ВМ запущена, создается vPE, чтобы хост мог получить доступ к vVols в группе ANA. На диаграмме ниже вы можете увидеть, что vPE указывает на группу ANA на массиве.
NS (пространство имен, эквивалент LUN в NVMe)
Каждый тип vVol (Config, Swap, Data, Mem), созданный и использующийся машиной, создает NS, который находится в группе ANA. Это соотношение 1:1 между vVol и NS позволяет вендорам оборудования легко масштабировать объекты vVols. Обычно поставщики поддерживают тысячи, а иногда и сотни тысяч NS. Ограничения NS будут зависеть от модели массива.
На диаграмме вы можете увидеть, что сама виртуальная машина является NS, это будет Config vVol, а диск - это другой NS, Data vVol.
Поддержка 256 пространств имен и 2K путей с NVMe-TCP и NVMe-FC
NVMeoF продолжает набирать популярность по очевидным причинам - более высокая производительность и пропускная способность по сравнению с традиционным подключением SCSI или NFS. Многие производители хранилищ также переходят на NVMe-массивы и использование SCSI для доступа к NVMe флэш-накопителям является узким местом и потенциалом для улучшений.
Продолжая работать на этим, VMware увеличила поддерживаемое количество пространств имен и путей как для NVMe-FC, так и для TCP.
Расширение reservations для устройств NVMe
Добавлена поддержка команд reservations NVMe для использования таких решений, как WSFC. Это позволит клиентам использовать возможности кластеризованных дисков VMDK средствами Microsoft WSFC с хранилищами данных NVMeoF. Пока поддерживается только протокол FC.
Поддержка автообнаружения для NVMe Discovery Service на ESXi
Расширенная поддержка NVMe-oF в ESXi позволяет динамически обнаруживать совместимые со стандартом службы NVMe Discovery Service. ESXi использует службу mDNS/DNS-SD для получения информации, такой как IP-адрес и номер порта активных служб обнаружения NVMe-oF в сети.
Также ESXi отправляет многоадресный DNS-запрос (mDNS), запрашивая информацию от сущностей, предоставляющих службу обнаружения DNS-SD. Если такая сущность активна в сети (на которую был отправлен запрос), она отправит (одноадресный) ответ на хост с запрошенной информацией - IP-адрес и номер порта, где работает служба.
16. Улучшение очистки дискового пространства с помощью Unmap
Снижение минимальной скорости очистки до 10 МБ/с
Начиная с vSphere 6.7, была добавлена функция настройки скорости очистки (Unmap) на уровне хранилища данных. С помощью этого улучшения клиенты могут изменять скорость очистки на базе рекомендаций поставщика их массива. Более высокая скорость очистки позволяла многим пользователям быстро вернуть неиспользуемое дисковое пространство. Однако иногда даже при минимальной скорости очистки в 25 МБ/с она может быть слишком высокой и привести к проблемам при одновременной отправке команд Unmap несколькими хостами. Эти проблемы могут усугубляться при увеличении числа хостов на один датастор.
Пример возможной перегрузки: 25 МБ/с * 100 хранилищ данных * 40 хостов ~ 104 ГБ/с
Чтобы помочь клиентам в ситуациях, когда скорость очистки 25 МБ/с может приводить к проблемам, VMware снизила минимальную скорость до 10 МБ/с и сделала ее настраиваемой на уровне датасторов:
При необходимости вы также можете полностью отключить рекламацию пространства для заданного datastore.
Очередь планирования отдельных команд Unmap
Отдельная очередь планирования команд Unmap позволяет выделить высокоприоритетные операции ввода-вывода метаданных VMFS и обслуживать их из отдельных очередей планирования, чтобы избежать задержки их исполнения из-за других команд Unmap.
17. Контейнерное хранилище CNS/CSI
Теперь вы можете выбрать политику Thin provisioning (EZT, LZT) через SPBM для CNS/Tanzu.
Цель этого - добавить возможность политик SPBM для механизма создания/изменения правил политик хранения, которые используются для параметров выделения томов. Это также облегчает проверку соответствия правил выделения томов в политиках хранения для SPBM.
Операции, поддерживаемые для виртуальных дисков: создание, реконфигурация, клонирование и перемещение.
Операции, поддерживаемые для FCD: создание, обновление политики хранения, клонирование и перемещение.
18. Улучшения NFS
Инженеры VMware всегда работают над улучшением надежности доступа к хранилищам. В vSphere 8 были добавлены следующие улучшения NFS, повышающие надежность:
Повторные попытки монтирования NFS при сбое
Валидация монтирования NFS
Ну как вам работа ChatGPT с правками человека? Читабельно? Напишите в комментариях!
На днях компания VMware объявила о том, что решения VMware Cloud on AWS Terraform Provider и Python Automation Utility for VMware Cloud on AWS теперь поддерживают аутентификацию приложений OAuth 2.0 для VMware Cloud, что позволяет зарегистрировать средства автоматизации с поддержкой этого типа аутентификации. Теперь администраторы могут управлять учетными данными, привязанными к API-токенам доступа отдельных разработчиков, на уровне организации.
Объекты OAuth app действуют как сущности в рамках коммуникаций server-to-server и могут быть использованы в разных организациях. Только пользователь, создавший API-токен, может управлять им, а владелец OAuth app - это организация, которая управляется администратором с ролью Developer. Поэтому для использования API, где не требуется связывание токена с пользователем (например, полностью автоматизированные решения), рекомендуется не использовать API-токены персональных аккаунтов.
Это позволяет избежать ситуации, когда аккаунт этого человека был деактивирован или устарел, для него изменилась роль и т.п., что может повлиять на сервисы, использующие этот токен. Вместо этого владелец объекта Organization создает OAuth App с App ID и App Secret, чтобы дать доступ приложению по API. Детали этого процесса на платформе VMware Cloud on AWS приведены вот в этой статье.
Итак, здесь есть 2 важных шага по созданию OAuth: создать объект App и назначить его объекту Org.
Для создания App нужно сделать следующее:
Логинимся в CSP, кликаем на имя пользователя и выбираем для него View Organization
Переходим на вкладку OAuth Apps в самом верху страницы
Нажимаем Create App и выбираем Server to server app
Определяем имя приложения, описание, время жизни токена (Access Token TTL, рекомендуется 30 минут). Надо помнить, что как только токен создан - уже нет способа отозвать доступ, поэтому не надо задавать слишком большое время.
Нажимаем Create. Надо помнить, что стоит максимально ограничивать роли для сервисов и действий в рамках организации минимально необходимыми привилегиями.
Скачиваем копию App ID и App Secret.
Помните, что после этого экрана вы уже не сможете скачать App Secret, но вы можете просмотреть App ID, а сам App Secret можно сгенерировать снова. Другие свойства приложения также можно редактировать после создания.
Назначаем объект App объекту Org:
Нажимаем Add после того, как вы создали App, чтобы добавить приложение в текущую организацию.
Переходим на страницу OAuth Apps со страницы View Organization (у пользователя должны быть права по добавлению в эту организацию)
Последний релиз VMware Cloud on AWS Terraform Provider был обновлен и теперь включает два новых поля в файле переменных variables.tf: client_id и client_secret. Параметр client_id - это идентификатор объекта OAuth App, ассоциированный с организацией, а client_secret - это его пароль. Оба этих параметра вместе используются для аутентификации при вызове VMware Cloud Services API. Помимо этой комбинации, вы можете использовать и один параметр api_token.
Решение Python Automation Utility for VMware Cloud on AWS также было обновлено, чтобы поддерживать метод аутентификации OAuth 2.0 app. Чтобы использовать его, нужно указать параметры oauth_clientId и oauth_clientSecret в файле config.ini, как показано в примере ниже:
По умолчанию механизм аутентификации использует API-токен, указанный в поле refresh_Token файла config.ini. Чтобы использовать новый метод аутентификации OAuth app, нужно добавить параметр -oauth при запуске команд, указанных ниже.
Пример команды для использования аутентификации по умолчанию с использованием refresh_Token:
./pyVMC.py sddc show-sddcs
А вот так нужно запускать эту команду для использования аутентификации OAuth app:
./pyVMC.py sddc show-sddcs –oauth
Для получения полного списка команд и инструкций по использованию средства Python Utility for VMware Cloud on AWS обратитесь к этому документу.
В марте компания VMware анонсировала скорую доступность первого пакета обновлений своей флагманской платформы виртуализации VMware vSphere 8.0 Update 1. Напомним, что прошлая версия VMware vSphere 8.0 была анонсирована на конференции VMware Explore 2022 в августе прошлого года.
Давайте посмотрим, что нового появилось в vSphere 8.0 U1:
1. Полная поддержка vSphere Configuration Profiles
В vSphere 8.0 эта функциональность впервые появилась и работала в режиме технологического превью, а в Update 1 она полностью вышла в продакшен. Эта возможность представляет собой новое поколение инструментов для управления конфигурациями кластеров и заменяет предыдущую функцию Host Profiles. Ее особенности:
Установка желаемой конфигурации на уровне кластера в форме JSON-документа
Проверка хостов на соответствие желаемой конфигурации
При выявлении несоответствий - перенастройка хостов на заданный уровень конфигурации
В vSphere 8 Update 1 возможности Configuration Profiles поддерживают настройку распределенных коммутаторов vSphere Distributed Switch, которая не была доступна в режиме технологического превью. Однако, окружения, использующие VMware NSX, все еще не поддерживаются.
Существующие кластеры можно перевести под управление Configuration Profiles. Если для кластера есть привязанный профиль Host Profile, то вы увидите предупреждение об удалении профиля, когда кластер будет переведен в Configuration Profiles. Как только переход будет закончен, Host Profiles уже нельзя будет привязать к кластеру и хостам.
Если кластер все еще использует управление жизненным циклом на базе бейзлайнов, то сначала кластер нужно перевести в режим управления image-based:
vSphere Configuration Profiles могут быть активированы при создании нового кластера. Это требует, чтобы кластер управлялся на основе единого определения образа. После создания кластера доступна кастомизация конфигурации. Более подробно о возможностях Configuration Profiles можно почитать здесь.
2. vSphere Lifecycle Manager
для отдельных хостов
В vSphere 8 появилась возможность управлять через vSphere Lifecycle Manager отдельными хостами ESXi под управлением vCenter посредством vSphere API. В Update 1 теперь есть полная поддержка vSphere Client для этого процесса - создать образ, проверить и привести в соответствие, а также другие функции.
Все, что вы ожидаете от vSphere Lifecycle Manager для взаимодействия с кластером vSphere, вы можете делать и для отдельных хостов, включая стейджинг и функции ESXi Quick Boot.
Также вы можете определить кастомные image depots для отдельных хостов - это полезно, когда у вас есть хост, который находится на уровне edge и должен использовать depot, размещенный совместно с хостом ESXi, во избежание проблем с настройкой конфигурации при плохом соединении удаленных друг от друга хостов ESXi и vCenter.
3. Различные GPU-нагрузки хоста на базе одной видеокарты
В предыдущих версиях vSphere все рабочие нагрузки NVIDIA vGPU должны были использовать тот же самый тип профиля vGPU и размер памяти vGPU. В vSphere 8 U1 модули NVIDIA vGPU могут быть назначены для различных типов профилей. Однако, размер памяти для них должен быть, по-прежнему, одинаковым. Например, на картинке ниже мы видим 3 виртуальных машины, каждая с разным профилем (B,C и Q) и размером памяти 8 ГБ. Это позволяет более эффективно разделять ресурсы между нагрузками разных видов.
NVIDIA позволяет создавать следующие типы профилей vGPU:
Profile type A - для потоково доставляемых приложений или для решений на базе сессий
Profile type B - для VDI-приложений
Profile type C - для приложений, требовательных к вычислительным ресурсам (например, machine learning)
Profile type Q - для приложений, требовательных к графике
4. Службы Supervisor Services для vSphere Distributed Switch
В vSphere 8 Update 1, в дополнение к VM Service, службы Supervisor Services теперь доступны при использовании сетевого стека vSphere Distributed Switch.
Supervisor Services - это сертифицированные в vSphere операторы Kubernetes, которые реализуют компоненты Infrastructure-as-a-Service, тесно интегрированные со службами независимых разработчиков ПО. Вы можете установить и управлять Supervisor Services в окружении vSphere with Tanzu, чтобы сделать их доступными для использования рабочими нагрузками Kubernetes. Когда Supervisor Services установлены на Supervisors, инженеры DevOps могут использовать API для создания инстансов на Supervisors в рамках пользовательских пространств имен.
Возможность VM Service была доработана, чтобы поддерживать образы ВМ, созданные пользователями. Теперь администраторы могут собирать собственные пайплайны сборки образов с поддержкой CloudInit и vAppConfig.
Администраторы могут добавить эти новые шаблоны ВМ в Content library, чтобы они стали доступны команде DevOps. А сами DevOps создают спецификацию cloud-config, которая настроит ВМ при первой загрузке. Команда DevOps отправляет спецификацию ВМ вместе cloud-config для создания и настройки ВМ.
DevOps могут теперь получать простой доступ к виртуальным машинам, которые они развернули, с использованием kubectl.
В этом случае создается уникальная ссылка, по которой можно получить доступ к консоли ВМ, и которая не требует настройки разрешений через vSphere Client. Веб-консоль дает по этому URL доступ пользователю к консоли машины в течение двух минут. В этом случае нужен доступ к Supervisor Control Plane по порту 443.
Веб-консоль ВМ дает возможности самостоятельной отладки и траблшутинга даже для тех ВМ, у которых может не быть доступа к сети и настроенного SSH.
7. Интегрированный плагин Skyline Health Diagnostics
Теперь развертывание и управление VMware Skyline Health Diagnostics упростилось за счет рабочего процесса, встроенного в vSphere Client, который дает возможность просто развернуть виртуальный модуль и зарегистрировать его в vCenter.
Skyline Health Diagnostics позволяет вам:
Диагностировать и исправлять различные типы отказов в инфраструктуре
Выполнять проверку состояния компонентов (health checks)
Понимать применимость VMware Security Advisories и связанных элементов
Обнаруживать проблемы, которые влияют на апдейты и апгрейды продукта
Утилита использует логи, конфигурационную информацию и другие источники для обнаружения проблем и предоставления рекомендаций в форме ссылок на статьи KB или шагов по исправлению ситуации.
8. Улучшенные метрики vSphere Green Metrics
В vSphere 8.0 появились метрики, которые отображают потребление энергии виртуальными машинами с точки зрения энергоэффективности виртуального датацентра. В vSphere 8.0 Update 1 теперь можно отслеживать их на уровне отдельных ВМ. Они берут во внимание объем ресурсов ВМ, чтобы дать пользователю более точную информацию об энергоэффективности на уровне отдельных нагрузок. Разработчики также могут получать их через API, а владельцы приложений могут получать агрегированное представление этих данных.
Метрика Static Power - это смоделированное потребление мощности простаивающих ресурсов ВМ, как если бы она был хостом bare-metal с такими же аппаратными параметрами процессора и памяти. Static Power оценивает затраты на поддержание таких хостов во включенном состоянии. Ну а Usage - это реально измеренное потребление мощности ВМ в активном режиме использования CPU и памяти, которые запрашиваются через интерфейс (IPMI - Intelligent Platform Management Interface).
9. Функция Okta Identity Federation для vCenter
vSphere 8 Update 1 поддерживает управление идентификациями и многофакторной аутентификацией в облаке, для чего на старте реализована поддержка Okta.
Использование Federated identity подразумевает, что vSphere не видит пользовательских учетных данных, что увеличивает безопасность. Это работает по аналогии со сторонними движками аутентификации в вебе, к которым пользователи уже привыкли (например, логин через Google).
10. Функции ESXi Quick Boot для защищенных систем
vSphere начала поддерживать Quick Boot еще с версии vSphere 6.7. Теперь хосты с поддержкой TPM 2.0 проходят через безопасный процесс загрузки и аттестации, что позволяет убедиться в неизменности хоста - а это надежный способ предотвратить атаки malware. Quick Boot теперь стал полноценно совместимым процессом в vSphere 8 Update 1.
11. Поддержка vSphere Fault Tolerance с устройствами vTPM
Функции непрерывной доступности VMware vSphere Fault Tolerance (FT) позволяют подхватить исполнение рабочей нагрузки на резервном хосте без простоя в случае проблем основной ВМ. Теперь эта функция поддерживает ВМ, настроенные с устройствами vTPM.
Модели Virtual TPM - это важный компонент инфраструктуры, используемый такими решениями, как Microsoft Device Guard, Credential Guard, Virtualization-Based Security, Secure Boot & OS attestation, а также многими другими. Это, зачастую, и часть регуляторных требований комплаенса.
12. Поддержка Nvidia NVSwitch
В рамках партнерства с NVIDIA, VMware продолжает расширять поддержку продуктового портфеля этого вендора.
Эта технология используется в high-performance computing (HPC) и для AI-приложений (deep learning, научное моделирование и анализ больших данных), что требует работы модулей GPU совместно в параллельном режиме. В современном серверном оборудовании различные приложения ограничены параметрами шины. Чтобы решить эту проблему, NVIDIA создала специальный коммутатор NVSwitch, который позволяет до 8 GPU взаимодействовать на максимальной скорости.
Вот нюансы технологий NVLink и NVSwitch:
NVLink - это бэкенд протокол для коммутаторов NVSwitch. NVLink создает мост для соединений точка-точка и может быть использован для линковки от 2 до 4 GPU на очень высокой скорости.
NVSwitch требует, чтобы более 4 GPU были соединены, а также использует поддержку vSphere 8U1 NVSwitch для формирования разделов из 2, 4 и 8 GPU для работы виртуальных машин.
NVLink использует архитектуру Hopper, что предполагает создания пары GPU, которые передают до 450 GB/s (то есть общая скорость до 900 GB/s).
Для сравнения архитектура Gen5 x16 может передавать на скорости до 64 GB/s, то есть NVLink и NVSwitch дают очень существенный прирост в скорости.
13. Функции VM DirectPath I/O Hot-Plug для NVMe
В прошлых релизах добавление или удаление устройств VM DirectPath IO требовало нахождения ВМ в выключенном состоянии. Теперь же в vSphere 8 Update 1 появилась поддержка горячего добавления и удаления устройств NVMe через vSphere API.
На этом пока все, в следующих статьях мы расскажем об улучшениях Core Storage в vSphere 8 Update 1.
На днях на сайте проекта VMware Labs появилось очередное обновление полезной утилиты vSphere Software Asset Management Tool 1.5, предназначенной для сбора подробной информации об инсталляции VMware vSphere на вашей площадке, касающейся лицензирования, а именно - инвентаря и доступности лицензий. Напомним, что в последний раз мы упоминали о ней вот тут. Это была версия 1.3, поэтому сегодня посмотрим, что нового появилось в версиях 1.4 и 1.5.
Итак, нововведения версии 1.5:
Полная поддержка последней версии платформы vSphere 8.0 - все работает, можно строить отчеты.
Новое в версии 1.4:
Добавлена возможность вывода в файл в формате JSON. Этот файл имеет те же данные, что и файл PDF, но более удобен для доступа из различного стороннего ПО.
Добавлен воркэраунд для запуска утилиты в окружении Java версий выше, чем 8. Более подробно об этом рассказано в руководстве пользователя.
Поддержка целевых файлов без строчки заголовка в начале.
Скачать vSphere Software Asset Management Tool 1.5 можно по этой ссылке.
На сайте проекта VMware Labs появилось обновление продукта ESXi Arm Edition 1.12. Напомним, что это решение представляет собой гипервизор для архитектуры ARM на базе кода ESXi. В будущем он найдет свое применение в таких решениях, как Project Monterey. О прошлой версии ESXi для ARM 1.11 мы писали в октябре прошлого года.
Давайте посмотрим, что нового в ESXi Arm Edition 1.12:
1. Улучшения технологии виртуализации
Различные улучшения в комплаенсе Arm SystemReady для виртуального аппаратного обеспечения, транслируемого в гостевые ОС
Исправления ошибок совместимости для механизма secure boot
2. Улучшения поддержки хостов
Экспериментальная поддержка серверов HPE ProLiant RL300 Gen11 и платформ на базе Marvell OCTEON 10
Поддержка NVMe на безкэшевых комплексах PCIe root (например, системы Rockchip RK3566, такие как Pine64 Quartz64 и Firefly Station M2)
Добавлен воркэраунд для устройств с PCI vendor/device ID 126f:2263 (например, Patriot M.2 P300), которые передают неуникальные идентификаторы EUI64/NGUID, которые не давали возможности обнаруживать более одного диска на системах с несколькими накопителями. При обновлении на версию 1.12 из предыдущих релизов эти устройства не будут смонтированы по умолчанию, чтобы это сделать прочитайте инструкцию вот тут.
В начале года компания VMware выпустила решение Aria Operations for Applications, предназначенное для облачных провайдеров, которое позволяет их клиентам наблюдать за инфраструктурой контейнеризованных приложений на платформе Tanzu. Ранее этот продукт назывался Tanzu Observability.
Решение позиционируется как платформа cloud-native observability, доступная для партнеров через портал Cloud Partner Navigator (CPN), которые участвуют в программе VMware Managed Service Providers (MSP). Aria Operations for Applications дает партнерам инструменты для команд DevOps, SecOps и SRE в части получения данных телеметрии, которые помогают планированию стратегии управления приложениями, API, базами данных, очередями сообщений для публичных, частных и гибридных облаков.
Сегодня мы поговорим о функциональности Query Analyzer, которая появилась в последней версии продукта. Она позволяет анализировать запросы и подзапросы в ситуациях, когда в результате запроса на графике не отображаются данные с пометкой No Data:
Query Analyzer позволяет найти проблему в ваших запросах и понять причину отсутствующих данных, начать процедуру решения проблем, а также получить статистики производительности запросов и подзапросов.
Если вы используете переменные в ваших запросах, Query Analyzer заменяет переменные их актуальными на данный момент значениями. Например, если вы хотите проанализировать max(${latency}), где переменная latency равна ts(requests.latency, source="app-1*" or source="app2*", env="dev"), то в Query Analyzer вы увидите такой запрос:
max(ts(requests.latency, source="app-1*" or source="app2*", env="dev"))
Итак, как проанализировать запрос:
Нажимаем на имя графика, который показывает No Data для открытия режима правки.
Если у вас несколько запросов, то найдите тот, который хотите проанализировать.
Нажмите на иконку рядом с запросом и выберите пункт Query Analyzer, после чего он откроется.
Сам анализатор выглядит так:
Нажимаем кнопку Analyze, чтобы найти проблемный запрос. В результате подзапрос, который вызывает проблему, будет подсвечен:
Здесь можно увидеть информацию о найденных проблемах:
У ситуации No Data может быть несколько причин, например:
Опечатка в запросе
В Aria Operations for Applications действительно нет данных для этого запроса
Запрос содержит один или несколько подзапросов, результат которых не содержит данных
Также на скриншоте выше вы видите, что Query Analyzer показывает статистики производительности на уровне подзапросов, содержащие 3 параметра:
Cardinality - число уникальных снятий данных в рамках временного интервала запроса (unique time series).
Points Scanned - число датапоинтов, которое использовалось для вывода графика на экран.
Duration - время между началом исполнения запроса и получением результата.
Если запрос содержит более одного подзапроса, который содержит No Data, то когда вы анализируете запрос, то первый подзапрос с пустыми данными будет отображен в разделе Detected Issues. Остальные подзапросы с No Data будут подчеркнуты пунктиром - их также можно развернуть для просмотра обнаруженных проблем.
Более подробно о функционале Query Analyze можно почитать в документации.
Недавно компания VMware объявила о выпуске обновленной версии облачной платформы Aria Automation Cloud 8.11.2 (релиз March 2023), предназначенной для автоматизации операций виртуальной инфраструктуры VMware vSphere на платформе VMware Cloud. Напомним, что о возможностях февральского релиза Aria Automation Cloud 8.11 мы рассказывали вот тут.
Давайте посмотрим, что там нового:
1. Обновления плагина Salt Master
Теперь SaltStack Config дает возможность апгрейда Master-плагина на последнюю версию напрямую из пользовательского интерфейса. Рабочее пространство Master Plugins имеет функцию обновления версии выбранного плагина на узле Salt master, чтобы его версия соответствовала версии VMware Aria Automation Config. Эта возможность дает пользователям инструменты для обеспечения соответствия синхронизации версий плагинов на облачных инстансах.
2. Новые возможности в инфраструктуре Azure
Поддержка операций Day 0 на ярусах performance tiers - теперь она предоставляется для дисков, управляемых в рамках Azure Premium. Используя VMware Cloud Template, пользователи могут указать ярус производительности в свойствах для дисков под управлением Azure.
Поддержка регионов Azure for US Government - теперь данные регионы поддерживаются как эндпоинты. Американские пользователи типа Federal и State Public теперь полностью поддерживаются в облаке Azure Cloud.
3. Локальный репозиторий VMware Aria Automation Orchestrator для окружений polyglot
Теперь пользователи VMware Aria Automation Orchestrator могут указать локальный репозиторий для окружения polyglot, из которого могут быть загружены зависимости (dependencies). После добавления кастомных репозиториев и определения их в рамках окружения, пользователи могут выбрать загрузку зависимостей из них на странице Action Environments. Это дает больше гибкости при управлении локальными репозиториями.
Больше подробностей о новых возможностях релиза Aria Automation Cloud 8.11.2 приведено в Release Notes.
Это шестая (заключительная) часть нашего большого рассказа о новых возможностях главного решения для резервного копирования и репликации виртуальных машин компании Veeam - Backup & Replication v12, которое уже доступно для скачивания.
В этой части мы поговорим об улучшениях Secondary Storage, бэкапе хранилищ на пленку, поддержке различных платформ, решении Cloud Connect, улучшениях API и REST API для бэкап-серверов. Поехали.
1. Secondary Storage
Новое для ExaGrid:
Fast cloning support — теперь появилась расширенная поддержка функционала нативного клонирования блоков, которая реализована в версии ExaGrid 6.2. В этой версии была существенно улучшена производительность процесса создания синтетических бэкапов.
Улучшения Dell Data Domain:
Longer incremental backup chains - максимальное число инкрементов до следующего периодического бэкапа увеличилось до 120 точек восстановления для того, чтобы соответствовать новым лимитам масштабируемости Data Domain.
DD OS and DD Boost support - была добавлена поддержка DD OS версий до 7.10, также обновилась поддержка DD Boost SDK до версии 7.7.1 LTS.
Поддержка HPE StoreOnce:
HPE StoreOnce immutability support - теперь поддерживаются неизменяемые бэкапы на хранилищах Catalyst Stores с включенной функцией ISV Controlled Data Immutability. Это требует того, чтобы хранилища были в режиме compliance, который, в свою очередь, вовлекает функцию Dual Authorization, которая эффективно запрещает модификацию и удаление неизменяемых файлов администраторами StoreOnce без утверждения со стороны Security Officer. Для этого нужна версия firmware 4.3.2 или более поздняя.
Fixed block size chunking - в этой версии появилась настройка Enforce fixed block chunking для вновь созданных хранилищ Catalyst, которая улучшает производительность инкрментальных и синтетических бэкапов до 4-5 раз на один поток (на основе собственных тестов HPE) в сравнении с механизмом variable block processing. Это улучшение производительности достигается за счет использования файлов бэкапа fixed block chunking в Catalyst Client, которые были предварительно выровнены Veeam посредством механизма Align backup file data blocks backup repository. Для этого также нужна версия firmware 4.3.2 или более поздняя.
HPE Cloud Bank Storage support - теперь вы можете применять HPE Cloud Bank Storage (расширение HPE StoreOnce Catalyst) для использования внешних недорогих объектных хранилищ в качестве целевых репозиториев для задач Catalyst Copy, что помогает снизить затраты на долговременное хранение. Опять-таки, для этого требуется версия firmware 4.3.2 или более поздняя.
Catalyst Copy support for more platforms - бэкапы, которые создавались Veeam Agents for Microsoft Windows и Linux в режимах managed-by-agent и standalone, а также бэкапы, созданные Veeam Backup for Nutanix AHV и Veeam Backup for Red Hat Virtualization, теперь можно использовать как источник для задач Catalyst Copy.
Поддержка Infinidat InfiniGuard:
В этой версии появилась нативная интеграция с Infinidat InfiniGuard, включая отдельный мастер в интерфейсе, с логикой обнаружения хранилищ и поддержкой функций native block cloning.
Поддержка Fujitsu CS800:
В этой версии появилась нативная интеграция с Fujitsu CS800, включая отдельный мастер в интерфейсе, с логикой обнаружения хранилищ и поддержкой функций native block cloning.
2. Бэкап на ленту
Процесс резервного копирования:
Backup Expanded workload support - задачи Backup-to-Tape теперь поддерживают экспорт любых копий бэкапов, которые были созданы новыми типами мультиплатформенных задач Backup Copy в режимах Immediate или Periodic, вне зависимости от типа рабочей нагрузки.
Virtual synthetic performance - расширенная технология компонента data fetcher теперь используется для NAS-репозиториев, что существенно увеличивает производительность экспорта synthetic-full бэкапов.
GFS monthly fulls with daily incrementals - бэкапы на daily media set теперь могут быть настроены как periodic monthly full backups в дополнение к уже доступной опции weekly full backup. Это дает дополнительную гибкость в ротации ленточных носителей GFS.
Инфраструктура ленточных носителей:
Tape server on Linux - в дополнение к серверам Windows для копирования на ленту, теперь можно зарегистрировать ленточные библиотеки и носители, присоединенные к Linux-серверам.
LTO-9 support - вся функциональность для ленточных носителей теперь поддерживает процесс инициализации лент LTO-9 и теперь корректно ожидает окончания инициализации, а не отваливается по таймауту, когда он занимает много времени.
Tape auto-eject - ленточные носители теперь автоматически извлекаются из приводов ленточных библиотек по окончании операций Inventory и Catalog для предотвращения случайного стирания кассет.
Waiting for tape notification enhancements - задачи резервного копирования на ленту теперь посылают детальный отчет по почте, даже когда процесс завис в ожидании вмешательства со стороны администратора. Эта нотификация включает основные детали задачи, такие как имя библиотеки, медиа-пул, медиа-сет, последняя записанная кассета и информация о бэкапе на ленту, что позволяет найти наиболее подходящие кассеты для продолжения задачи РК.
Экспериментальные возможности:
Действуют для ключа реестра HKLM\SOFTWARE\Veeam\Veeam Backup and Replication, где можно создавать следующие значения:
Disable extra barcode scans - можно создать значение TapeSuspendBarcodeValidation (DWORD, 1) для того, чтобы предотвратить лишние сканирования баркодов при импорте ленточных носителей. Это может ускорить процесс миграции кассет между библиотеками, которые присоединены к одному бэкап-серверу.
Return expired tapes to free media pools - создание значения TapeMarkExpiredMediaFree (DWORD, 1) позволяет мгновенно вернуть любые устаревшие данные кассет в свободный медиа-пул. В этом режиме кассеты больше не будут постоянно назначаться в тот же медиа-пул при устаревании, что делает управление более запутанным. Также это позволяет максимизировать использование кассет в рамках медиа-пулов.
3. Поддержка различных платформ
Поддержка Microsoft Azure:
Azure AD application support - бэкап-серверы теперь могут использовать сервисные аккаунты Azure AD Applications для доступа к ресурсам Microsoft Azure, таким как подписки, группы ресурсов, аккаунты хранилищ и другие объекты.
Tags integration - теперь можно назначать тэги к восстановленным машинам Azure для того, чтобы убедиться, что они корректно категоризованы в соответствии с политиками.
Приложения Microsoft:
Microsoft SQL Server 2022 - теперь добавлена поддержка SQL Server 2022 для процессинга application-aware, бэкапа транзакционных логов и в Veeam Explorer for Microsoft SQL Server. В дополнение к этому, SQL Server 2022 теперь поддерживается для конфигурационной БД Veeam Backup & Replication.
Microsoft SharePoint Server Subscription Edition - добавлена поддержка последней версии SharePoint Server, включая процессинг application-aware и Veeam Explorer for Microsoft SharePoint.
System Center Virtual Machine Manager 2022 - появилась поддержка последней версии SCVMM.
Поддержка Windows:
Microsoft Windows Windows 10 22H2 и Windows 11 22H2 - теперь эти ОС поддерживаются в качестве гостевых для процессинга application-aware, для бэкапа на уровне агентов в режиме job protection и для установки Veeam Backup & Replication и его компонентов.
Поддержка Linux:
В этой версии добавлена поддержка следующих версий Linux для процессинга application-aware, бэкапа на уровне агентов в режиме job protection и для установки Veeam Backup & Replication и его компонентов:
Ubuntu 22.04
Red Hat Enterprise Linux (RHEL) 8.6, 8.7, 9.0 и 9.1
SUSE Linux Enterprise Server (SLES) 15 SP4
Oracle Linux (RHCK) 9.0 и 9.1
Только для agent-based бэкапов поддерживаются следующие ОС:
Oracle Linux (UEK) 9
Fedora 36 и 37
openSUSE Leap 15.4
Поддержка VMware vSphere:
VMware vSphere vSphere 8.0 - в дополнение к базовой совместимости, которая появилась в версии V11a, эта версия имеет полную поддержку vSphere 8, включая ВМ с виртуальным железом версии 20, а также бэкапа и восстановления vSphere DataSets.
4. Улучшения Cloud Connect
CDP to Cloud Connect - в дополнение к регулярным задачам репликации, политики CDP теперь могут применяться к облачным хостам из консоли Veeam Cloud Connect. На стороне сервис-провайдера поддерживаются в качестве таргетов как VMware vSphere, так и VMware Cloud Director.
Instant Recovery as a Service - сервис-провайдеры BaaS теперь могут мгновенно восстановить любую рабочую нагрузку клиента в виде ВМ vSphere путем запуска их напрямую из незашифрованных бэкапов, хранящихся в облачных репозиториях.
Instant Recovery for Nutanix AHV backups - клиенты провайдеров теперь могут мгновенно восстанавливать машины AHV из бэкапов, хранящихся в облачных репозиториях.
Stronger NEA encryption algorithm - для повышенной безопасности были обновлены криптографические алгоритмы, используемые модулями Network Extension Appliances (NEA).
Rental licensing enhancement - входящие cloud-native бэкапы, которые были созданы посредством Veeam Backup for AWS / for Microsoft Azure / for Google Cloud через механизм аренды лицензий теперь не потребляют поинты на стороне Veeam Cloud Connect.
5. Улучшения API
Улучшения PowerShell:
Upgrade to per-machine metadata - этот новый командлет предназначен для апгрейда метаданных цепочки бэкапов, что полезно для автоматического апгрейда большого парка бэкап-серверов.
Active Full and Retry operations - новые параметры в командлетах Start* позволяют автоматизировать обработку операций Active Full и Retry для отдельных машин в задаче РК.
Detach backups - этот командлет позволяет исключить бэкапы из задачи. Эти бэкапы будут отображаться на узле Orphaned node в разделе Backups с последней актуальной для них политикой хранения.
Apply retention policy - новый командлет для гранулярного применения политики хранения к выбранным бэкапам.
VeeaMover - новые командлеты для перемещения машин между задачами, а также для перемещения и копирования бэкапов между репозиториями.
Mount to backup console - новый командлет для монтирования бэкапов к серверу с backup console.
Compare with production - новые командлеты и параметры, которые позволяют сравнивать файлы в выбранной точке восстановления с производственной машиной, а также восстанавливать только изменившиеся объекты.
Stop recovery session - новый командлет для остановки сессий восстановления file-level и item-level, а также размонтирования опубликованных бэкапов.
Instant recovery to a Hyper-V VM - новый набор командлетов для мгновенного восстановления бэкапов на уровне образов с любой платформы в среду Microsoft Hyper-V.
Instant recovery for tenant backups - новый набор командлетов для мгновенного восстановления бэкапов клиентов на инфраструктуру провайдера.
Улучшения REST API для бэкап-серверов:
Backup server info - новый эндпоинт с информацией о версии бэкап-сервера, билде и уровне патчей.
SOBR management - возможность контроля режима экстентов, эвакуации бэкапов, ребалансировки и управления разрешениями SOBR access.
vSphere tags support - возможность указать тэги в настройках задачи РК, включая процессинг application-aware.
Entire VM restore - добавлена поддержка восстановления любых ВМ, кроме режима Staged Restore.
Instant VM Recovery - добавлена полная поддержка управления мгновенным восстановлением, миграцией в производственную среду и получение коллекции всех активных монтирований instant recovery.
Recovery tokens - добавлена поддержка операций CRUD для токенов agent recovery, включая пролонгацию даты их устаревания.
На этом заканчивается наш подробный обзор всех новых функций Veeam Backup & Replication v12. Скачать пробную версию продукта можно бесплатно по этой ссылке.
На днях компания VMware выпустила полезный для администраторов инфраструктуры виртуальных десктопов документ App Volumes 4 Evaluation Guide. Напомним, что решение App Volumes предназначено для быстрой доставки приложений в виртуальные среды VMware Horizon без необходимости их установки с широкими возможностями по управлению ими (в том числе, для legacy-приложений).
Данный документ представляет собой подробное руководство по первичному развертыванию продукта App Volumes с подробным объяснением работы данной технологии, составляющих компонентов и взаимосвязей между ними, описанием процесса упаковки приложений, а также реальными примерами использования различных функций.
Основные разделы документа:
Architecture and Components
App Volumes Manager Installation and Initial Configuration
Setup of Packaging VMs and Endpoint VMs
Simplified Application Management with App Volumes (Exercises)
Скачать VMware App Volumes 4 Evaluation Guide можно по этой ссылке, обновляемая онлайн-версия находится тут.
На днях компания VMware объявила о прекращении поддержки протокола PCoIP, который использовался для передачи данных удаленных десктопов на клиентское устройство в решении VMware Horizon. Напомним, что изначально этот протокол был разработан совместно компаниями VMware и Teradici, после чего вошел в состав решения VMware View 4 (сейчас актуальна уже восьмая версия этой платформы). Было это в далеком 2009 году.
Со временем на смену PCoIP пришел высокопроизводительный протокол Blast (ранее он назывался AppBlast и был анонсирован в 2011 году, а в релиз вышел в 2013), который поначалу развивался параллельно с PCoIP, но сейчас показывает лучшие результаты и является основным протоколом доставки. В связи с этим, разработка PCoIP под Horizon была остановлена, а недавно было принято решение об прекращении его поддержки.
Сейчас протокол Blast Extreme обеспечивает высокопроизводительную доставку виртуальных десктопов и приложений как во внутрикорпоративных сетях, так и через WAN-сети и интернет:
VMware по-прежнему будет включать PCoIP как опцию для протокола передачи в Horizon Client и Horizon Agent до конца 2025 года в целях поддержки существующей базы пользователей. За следующие пару лет протокол PCoIP будет исчезать из продуктов VMware, но, согласно политике компании, продукты Horizon поддерживаются еще в течение трех лет с момента релиза, так что PCoIP теоретически будет поддерживаться до 2028 года.
Во многом дело еще в том, что протокол PCoIP разрабатывается компанией Teradici, купленной HP в 2021 году, и теперь это HP Teradici. Ну а HP - это не VMware, для которой важно иметь собственный протокол. VMware продолжит сотрудничество с HP Teradici в плане разработки высокопроизводительных протоколов, в частности в клиентах HP Anyware Zero Clients (подробнее об этом тут).
Осенью прошлого года VMware анонсировала первую версию фреймворка
PowervRLICloud, предназначенного для управления окружением VMware vRealize LogInsight Cloud (этот продукт сейчас называется Aria Operations for Logs). Это PowerShell модуль, который реализует абстракции VMware vRealize LogInsight Cloud API для простого доступа к возможностям функций управления этим решением посредством сценариев.
Недавно компания VMware напомнила своим партнерам и клиентам о том, что поддержка решения для виртуализации настольных ПК VMware Horizon 7 заканчивается 30 апреля.
О седьмой версии решения Horizon мы впервые писали в феврале 2016 года. Прошло уже 7 лет, поэтому поддержку продукта пора заканчивать, а пользователям следует переходить на VMware Horizon 8, последняя версия которого (2212) вышла в начале этого года.
На самом деле, поддержка решения Horizon 7 уже была прекращена для всех версий, кроме 7.13, еще в марте 2021 года, но к маю этого года уже все версии Horizon 7 окажутся в статусе End of Support (technical guidance для этой версии продолжится до 30 апреля 2025, но там со стороны VMware уже ничего не гарантируется).
Итак, основные моменты по миграции с Horizon 7 на Horizon 8 описаны в KB 89840. Перед проведением апгрейда можно также почитать следующие ресурсы:
Многие администраторы сталкиваются с необходимостью обновления пакета VMware Tools в большом количестве виртуальных машин, работающих на серверах ESXi платформы VMware vSphere.
Общие сведения об обновлении VMware Tools
На данный момент можно использовать один из трех способов массового VMware Tools в большой инфраструктуре:
Применение средства VMware vSphere Lifecycle Manager (ранее его функционал был частью VMware Update Manager)
Написание сценариев для фреймворка VMware vSphere PowerCLI
Использование сторонних утилит для обновления тулзов
В отличие от версий аппаратной обеспечения (VM Hardware), компания VMware рекомендует всегда использовать последнюю версию пакета VMware Tools, для которого есть матрицы совместимости с различными версиями хостов ESXi. Посмотреть их можно по этой ссылке.
Например, мы видим, что VMware Tools 2016 года все еще можно использовать в ВМ на ESXi 7.0 U3. Также виртуальная машина на сервере VMware ESXi 5.5 может иметь текущую версию VMware Tools (сейчас это 12.1.5).
Напомним, что VMware Tools - это не только часть дистрибутива vSphere, но и отдельный продукт, который можно скачать с портала Customer Connect.
Есть несколько вариантов по загрузке этого пакета:
Бандл для общего репозитория Locker
(например, VMware-Tools-windows-12.1.5-20735119.zip) - он используется для создания локального или общего репозитория с нужной версией VMware Tools.
Установщик в гостевой ОС, который можно запустить в ней как исполняемый файл (VMware-tools-12.1.5-20735119-x86_64.exe.zip).
Пакеты для GuestStore
(gueststore-vmtools-12.1.5-20735119-20735876.zip) - это новая возможность, которая появилась в vSphere 7.0 U2. GuestStore сделан не для обновления VMware Tools, но может использоваться для этой цели (это тема для отдельной статьи).
Офлайн VIB-пакет с тулзами (VMware-Tools-12.1.5-core-offline-depot-ESXi-all-20735119.zip) - он используется как Baseline для обновления VMware Tools на хостах.
Исторически пакет VMware Tools, в основном, выпускался для Windows и Linux. Есть также версии этого пакета и для FreeBSD, Solaris и MacOS. Здесь есть следующие нюансы:
Начиная с версии VMware Tools 10.2.0, инсталляция на базе Perl-скриптов для FreeBSD больше не поддерживается. В этом случае также надо использовать open-vm-tools.
Последняя версия тулзов для гостевых ОС Solaris - это 10.3.10.
Как мы увидим дальше, очень важно знать, какая версия VMware Tools размещена локально на хосте ESXi после его установки. Эта версия может быть использована для проверки актуальных пакетов в виртуальных машинах. Для быстрой проверки текущей версии пакета на хосте можно использовать следующую команду:
esxcli software component get | grep VMware-VM-Tools -B 1 -A 14
Если вы хотите использовать для этого PowerCLI, то можно выполнить следующий сценарий:
Итак, рассмотрим обновление VMware Tools одним из двух способов:
Обновление VMware Tools как отдельного пакета ПО
В этом случае для нужно версии тулзов можно использовать любое средство, например Microsoft System Center, которое предназначено для массового развертывания программ. Также вы можете использовать любые скрипты и другие средства в режиме тихой установки (silent install).
Обновление VMware Tools посредством функционала vSphere
При развертывании и апгрейде хостов ESXi на них помещаются соответствующие версии VMware Tools (чтобы узнать список версий, загляните сюда). По умолчанию пакеты помещаются в папку /productLocker на хосте ESXi - это symbolic link, то есть просто указатель на настроенную папку. Чтобы узнать, какая версия VMware Tools является текущей, сервер vCenter сравнивает установленную версию тулзов в ВМ с версией, которая хранится в разделе /productLocker. Если актуальная версия в гостевой ОС меньше хранящейся на хосте, то в vSphere Client вы увидите соответствующее предупреждение:
Далее вам нужно выполнить процедуру, состоящую из двух основных шагов:
Настраиваем хост ESXi для использования определенной версии VMware Tools
Автоматизируем процесс обновления тулзов в гостевых ОС виртуальных машин
Шаг 1 - Настройка хоста ESXi для использования определенной версии VMware Tools
Надо сказать, что не рекомендуется вручную обновлять содержимое папки /productLocker, так как это не поддерживаемый официально процесс, и при апгрейде хоста вы можете получить более старую версию пакета. Также вы можете использовать конкретную версию VMware Tools для всех ВМ (например, ту, что содержит исправление конкретного бага).
Используем vSphere Lifecycle Manager для обновления VMware Tools на хостах ESXi
Это рекомендуемый способ обновления пакета VMware Tools, здесь может быть использован один из двух пакетов обновления хостов в кластере:
Если вы обновляете кластер, используя базовые уровни (baselines), вы можете создать кастомный образ, который включает желаемые версии VMware Tools, либо вы можете развернуть тулзы с использованием кастомного бейзлайна.
Давайте посмотрим на обновление с использованием метода Baseline:
Просто скачиваем VMware Tools Offline VIB bundle
Загружаем бандл на vSphere Lifecycle Manager (либо VIB-пакет может быть загружен этим продуктом автоматически)
Выполняем функцию Remediate для накатывания VMware Tools для ВМ на хостах ESXi
После успешного апдейта, локальный репозиторий VMware Tools также будет обновлен.
Несмотря на то, что хост не нужно перезагружать после обновления, он все равно должен быть помещен в режим обслуживания (maintenance mode). В противном случае, процесс обновления может выглядеть успешным, но в реальности изменений на хосте не произойдет.
Теперь посмотрим на процесс обновления VMware Tools методом Single Image:
В этом случае можно изменить только версию VMware Tools, а остальное можно оставить как есть.
Создаем общий репозиторий для нужной версии VMware Tools
Этот подход создает центральный репозиторий VMware Tools для нескольких хостов. В этом случае они не будут использовать локальный репозиторий, а на общем хранилище будет использоваться общая папка, которая станет новым репозиторием. Преимуществом данного подхода является обслуживание только одного экземпляра репозитория. Процесс создания этого репозитория описан в KB 2129825.
Как это выглядит по шагам:
1. Создаем на общем томе VMFS папку и устанавливаем для нее разрешения:
cd /vmfs/volumes/datastore
mkdir vmtools-repository-name
chmod 700 vmtools-repository-name
2. Если вы хотите использовать уже использованный репозиторий, то папку надо очистить:
3. Добавляем файлы, загруженные из Customer Connect и распакованные, в эту папку - у вас получится две подпапки, содержащие нужные файлы:
На скриншоте показан пример для VMware Tools под Windows. Если вы хотите использовать старые тулзы для Linux, то их нужно добавить в папку vmtools. Также посмотрите вот эту нашу статью о VMware Tools.
5. Если вы делаете процедуру впервые, то нужно настроить хосты ESXi для использования данной папки репозитория вместо используемой локальной папки по умолчанию. Для этого вам нужно добавить расширенную настройку UserVars.ProductLockerLocation (по умолчанию она указывает на /locker/packages/vmtoolsRepo/). Напомним, что /productLocker - это символьная ссылка, поэтому нужно использовать полный путь.
Так как мы обсуждаем массовое обновление тулзов, то имеет смысл показать здесь применение данного способа с использованием PowerCLI:
Для вывода текущей директории Locker выполняем следующий командлет:
Get-VMHost | Get-AdvancedSetting -Name "UserVars.ProductLockerLocation" | Select-Object Entity, Value
Для изменения директории выполняем такой командлет:
Будьте аккуратны при вызове второй команды, так как она меняет параметр на всех хостах, которые вы указали.
6. После этого вам нужно будет перезагрузить хост для обновления символьной ссылки /productLocker.
Шаг 2 - Автоматизация процесса обновления тулзов в гостевых ОС виртуальных машин
Теперь мы готовы автоматизировать апдейты VMware Tools в гостевой ОС. Так как мы говорим о массовом обновлении пакетов, то мы не будем обсуждать вариант с логином в гостевую ОС, монтирования ISO-образа и запуском exe-файла.
Сначала посмотрим, какие версии сейчас установлены в виртуальных машинах, с помощью PowerCLI. Запускаем следующую команду:
Это не самая удобная нотация, но она соответствует той, что мы видим на странице VM Summary на сервере vCenter. Для получения параметров этой команды используйте маппинг-файл версий.
4 способа автоматизации обновления VMware Tools в гостевой ОС:
1. Обновляем VMware Tools немедленно или ставим запланированную задачу через vCenter
Через интерфейс не всегда удобно работать с массовым обновлением, но в данном случае это можно сделать с помощью отфильтрованного списка ВМ и установки настроек по срабатыванию действий с объектами.
vSphere Lifecycle Manager имеет довольно мощный функционал в этом плане. Процесс обновления можно запланировать на базе состояния питания ВМ. Также можно задать опции предварительного создания снапшота ВМ.
Выбираем нужный кластер, идем на вкладку Updates и выбираем VMware Tools. Фильтруем нужные нам ВМ или выбираем все, далее кликаем Upgrade to match host. В следующих окнах у вас будет множество опций для создания запланированной задачи:
Вы можете не только настроить создания снапшота перед апдейтом, но и задать число часов, по истечении которых снапшот будет удален. Также в состав снапшота может входить и состояние оперативной памяти.
Также помните, что массовое удаление снапшотов в одно время может создать очень большую нагрузку на хранилище. Поэтому лучше снапшоты использовать только для самых критичных ВМ, которые должны сразу оказаться доступными в случае каких-либо проблем.
Дефолтные настройки для этих параметров вы можете установить здесь: Menu -> Lifecycle Manager -> Settings -> VMs:
2. Мгновенное обновление VMware Tools через vSphere PowerCLI
Для обновления тулзов на выбранных хостах (или всех) используется командлет Update-Tools. Он инициирует процесс обновления пакета изнутри гостевой ОС. По умолчанию Update-Tools ждет завершения обновления, после чего инициируется процесс перезагрузки ВМ. Это поведение можно изменить, используя параметры NoReboot и RunAsync.
Следующая команда начинает процесс обновления в виртуальной машине Win2019-01 в рамках задачи:
Get-VM Win2019-01 | Update-Tools –RunAsync
Чтобы посмотреть статус выполняемых задач, используйте команду Get-Task:
Так как это команда PowerShell - ее также можно добавить в запланированные задачи.
3. Обновление VMware Tools при следующей загрузке ВМ в интерфейсе vSphere Client
В рамках окна обслуживания виртуальные машины обычно можно перезагружать. Его, как раз, можно использовать и для обновления VMware Tools. Для этого надо настроить ВМ для проверки версии тулзов при загрузке. Если установленная версия меньше необходимой (по ссылке в /productLocker), то начинается процесс апдейта.
Для изменения политики обновлений, выберите нужный кластер и перейдите на вкладку Updates, где выберите VMware Tools. Там можно фильтровать список ВМ:
После того, как вы выберете машины, можно задать политику автообновления для них:
4. Обновление тулзов при следующей загрузке с использованием vSphere PowerCLI
Сначала посмотрим, текущую конфигурацию ВМ через PowerCLI:
Уделите особое внимание тому факту, какие ВМ вы поместите в переменную $VMs. При таком подходе для обновления VMware Tools вы не сможете запланировать создание предварительных снапшотов ВМ.
Публикуем пятую часть нашего большого рассказа о новых возможностях главного решения для резервного копирования и репликации виртуальных машин компании Veeam - Backup & Replication v12, которое уже доступно для скачивания.
В пятой части мы расскажем об улучшениях бэкап-консоли, новых функциях Enterprise Manager, возможностях установщика, лицензировании и интеграциях с хранилищами в части Primary Storage.
1. Бэкап-консоль
Granular operations — теперь можно перезапустить процессинг или выполнить бэкап Active Full для отдельных машин без инициирования этой операции для всех машин в задаче путем клика на соответствующую машину в сессии задачи.
Global exclusions list - управление постоянными или временными исключениями стало проще за счет возможности указания мастер-списка машин, которые вы хотите полностью исключить из процессинга, даже если они были добавлены в задачу по ошибке. Диалог Global Exclusions доступен из главного меню, также эти машины имеют выбранную опцию Disable processing на вкладке инвентаря.
Detach backups from a job - теперь можно отключить существующие бэкапы от задачи, что влечет за собой начало новой цепочки бэкапов во время следующего запуска полного бэкапа. Отключенные бэкапы будут отображаться в Orphaned-разделе вкладки Backups с последними известными данными об их политике хранения. Если вы хотите избежать этого, то можно использовать функцию Export Backup или создать новый Copy Backup вместо отключения бэкапов.
Dashboard redesign - дэшборды Workload и Storage registration были переработаны, чтобы упростить навигацию по растущему объему поддерживаемых платформ, вендорам хранилищ и их моделям, с которыми нативно интегрировано решение Veeam Backup & Replication.
Last backup time - теперь в списке машин на вкладке инвентаря отображается дата и время снятия последнего бэкапа.
Exported backup retention - если вы выбираете автоматическое удаление экспортированных, скопированных или VeeamZIP бэкапов, то дата удаления будет записана в логе сессии.
Repository membership and role - новые колонки в представлении репозитория показывают, является ли он extent member для SOBR, а также тип экстента (Performance, Capacity или Archive).
Instant recovery preferences - состояние чекбоксов на последней странице мастера Instant Recovery теперь сохраняется на уровне пользователя, чтобы быстрее выполнять восстановление.
Session initiator logging - все сессии Restore and System теперь отображают аккаунт пользователя, который инициировал операцию.
History tab improvements - все долгие активные сессии (например, без значения End Time) теперь показаны в верху списка при сортировке по End Time.
Update notification improvements - движок оповещения об обновлениях был улучшен, теперь он включает нотификации о кумулятивных патчах.
2. Функции Enterprise Manager
Общие улучшения:
Certificate-based authentication — теперь не нужно хранить креды бэкап-администратора для каждого управляемого бэкапа в конфигурационной базе данных. Как только бэкап-сервер регистрируется в Enterprise Manager, для коммуникации будут использоваться автоматически сгенерированные сертификаты.
Backup server preferences - теперь запоминается выбор бэкап-серверов на дэшборде и отображается там по умолчанию.
Improved email reports - были сделаны различные улучшения в отчете по почте в плане контента и верстки.
Export support logs - теперь запрошенные Veeam логи могут быть экспортированы с помощью новой функции Log Export.
Улучшения резервного копирования:
CDP for VMware Cloud Director — теперь доступно управление существующими политиками VCD CDP и их репликами в Enterprise Manager.
Catalyst Copy jobs - можно управлять задачами HPE StoreOnce Catalyst Copy через Enterprise Manager.
Quick backup - операции Quick Backup теперь можно запускать из Enterprise Manager для задач, управляемых агентами Managed-byServer.
High priority jobs - теперь можно менять приоритет задач в веб-интерфейсе и видеть наиболее приоритетные задачи в списках.
Улучшения процесса восстановления:
Instant VM Recovery - теперь выполнять восстановление машин и файловых шар VMware vSphere, VMware Cloud Director и Microsoft Hyper-V можно делать напрямую из бэкапов и снапшотов хранилищ прямо из веб-интерфейса. Это делает доступным восстановление в рамках операции Migrate to Production.
Restore to another location - в дополнение к in-place restores, вы можете проводить полное восстановление виртуальной машины на другой хост или хранилище, а также указывать все остальные параметры размещения.
PostgreSQL database restore - теперь можно восстанавливать экземпляры БД point-in-time из application-aware бэкапов серверов PostgreSQL и делегировать эту операцию администраторам БД и операторам техподдержки.
VM templates restore - теперь можно искать и восстанавливать шаблоны ВМ.
Exchange item-level restore improvements - теперь не нужно постоянной хранить аккаунт AD в БД Enterprise Manager, который является членом групп Domain Administrator или Organization Management. Вместо этого можно использовать его в интерактивном режиме с ограничениями по количеству почтовых ящиков при начале восстановления.
Search result sorting - выполнение восстановления на уровне файлов стало проще, так как файлы отсортированы по именам в результатах поиска.
3. Установщик
New setup experience - установщик был переработан, основные и важные функции сохранились, но были убраны лишние шаги и ненужные элементы. Теперь не нужно заботиться о предварительных условиях установки - нужно просто выбрать те чекбоксы параметров установки, которые вам доступны.
Streamlined upgrade - существенно была улучшена функциональность предварительных проверок для апгрейда, где теперь показываются все обнаруженные проблемы в удобном для использования формате. Теперь в отчете вы можете скопировать все детали найденных проблем и отправить их коллегам для исправления.
4. Лицензирование
Прежде всего надо отметить, что формат лицензий не менялся с 10-й версии продукта, поэтому вам не нужно будет обновлять их, и можно продолжить их использование и для V12.
Veeam Universal License (VUL):
Doubled license buffer - пользователи с функцией License auto update теперь могут использовать в два раза больший буфер лицензий, что дает возможность превысить использование лицензии VUL до 20% (или до 20 лицензий, в зависимости от того, что больше). Для этого нужно включить license update check, который должен выполняться хотя бы раз в месяц (то есть, нужно настроить сетевой экран соответствующим образом).
Улучшения Community Edition:
Community Edition Now with even more features - обновленный бесплатный продукт Veeam Backup & Replication Community Edition V12 получил еще больше новых возможностей и улучшений, доступных в версии V12. Подробнее об этом тут.
Cloud-native backups - решения Veeam Backup for Microsoft Azure, for AWS и for Google Cloud теперь включают издание Community Edition как часть бесплатной лицензии на 10 инстансов. Также доступен апгрейд с Community Edition на Veeam Data Platform Essentials.
5. Улучшения Primary Storage
Общие улучшения:
Storage discovery optimizations - логика автоматического ресканирования хранилищ была переработана, чтобы избежать ненужных сканирований, которые влияют на производительность. Вследствие этого было уменьшено количество "тяжелых" операций VMFS rescan, которые теперь случаются только при сборе информации о томах и снапшотах или обновлении томов.
Новая версия Universal Storage API v2:
Snapshot replication orchestration - задачи РК теперь могут использовать существующие связи репликации хранилищ для создания реплик на основе storage-based snapshot как дополнительных точек восстановления. Это позволяет снимать резервные копии из массивов secondary storage, чтобы избежать нагрузки на primary storage.
Snapshot archiving orchestration - теперь задача РК может управлять offload-операциями снапшотов хранилищ на других типах хранилищ, которые поддерживаются вендором, и отслеживать их как дополнительные точки восстановления.
Synchronous replication support - задачи РК могут создавать скоординированные снапшоты хранилищ, которые могут управляться как дополнительные точки восстановления на конфигурациях dual storage, которые служат как один том production volume из нескольких бэкэндов управления. Это предоставляет интеграцию с конфигурациями Active/Active и Active/HotStandby.
Для второй версии API (USAPI V2) пока полностью поддерживаются хранилища Pure Storage, другие вендоры будут добавляться по мере их присоединения к программе.
Хранилища Cisco HyperFlex:
Multi-vCenter configuration support - версия V12 использует новый HyperFlex API для VMware vCenter для управления хостами ESXi в окружениях, где есть несколько кластеров HyperFlex под управлением одного или нескольких серверов vCenter.
Хранилища IBM Spectrum Virtualize:
Volume replication orchestration - добавлена поддержка репликации снапшотов (например, Global Mirror), а также синхронной репликации (например, Metro Mirror и HyperSwap) для хранилищ типа IBM Spectrum Virtualize. Это добавляет поддержку массивов secondary storage для бэкапа из снапшотов хранилищ и задач snapshot-only.
Compressed snapshots support - для томов IBM FlashSystem с поддержкой аппаратного сжатия в модулях IBM FlashCore функция сжатия снапшотов включена и используется по умолчанию.
HPE Nimble and HPE Alletra 5000/6000:
Synchronous replication support — в V12 добавлена поддержка синхронной репликации и coordinated snapshots, включая конфигурации с Peer Persistence for application-transparent failover. Это дает поддержку secondary storage для бэкапов из снапшотов хранилищ и задач snapshot-only. Данная функциональность поддерживается для массивов HPE Nimble и HPE Alletra 5000/6000 на базе Nimble OS версии 5.1.4 и более поздних.
NetApp All SAN Array (ASA):
NetApp ASA support — в V12 добавлена поддержка NetApp ASA для интеграции со снапшотами хранилищ.
На этом заканчивается список функций для пятой части статьи. В завершающей статье о Veeam Backup & Replication v12 мы расскажем о Secondary storage, бэкапе на ленту, поддержке разных платформ, новых функциях Cloud Connect, а также улучшениях API и REST API для бэкап-серверов.
Скачать пробную версию продукта можно бесплатно по этой ссылке.
На сайте проекта VMware Labs вышла обновленная версия средства HCIBench 2.8.1, предназначенного для проведения комплексных тестов производительности отказоустойчивых кластеров хранилищ VMware vSAN, а также других конфигураций виртуальной инфраструктуры. О прошлой версии HCIBench 2.8 мы писали вот тут.
Давайте посмотрим, что нового в HCIBench 2.8.1:
Добавлена поддержка нескольких параметров учетных записей для серверов ESXi
Поля для коэффициентов сжатия и дедупликации добавлены для страниц Vdbench и Fio
Оптимизированная функция Easy-Run - добавлены коэффициенты compression/deduplication при тестировании датастора vSAN с включенным режимом dd/c
Компания VMware недавно выпустила новую версию своей основной платформы для виртуализации, агрегации и централизованного управления сетями виртуального датацентра VMware NSX 4.1. Напомним, что о прошлой версии этого решения - VMware NSX 4.0 - мы рассказывали вот тут.
Давайте посмотрим, что там появилось нового:
1. Отправка логов IDS/IPS к NDR
В NSX 4.1 появилась возможность отправки логов системы IDS/IPS от NSX Gateway firewall (GFW) к компоненту Network Detection and Response (NDR), который является частью продукта VMware NSX Advanced Threat Prevention (ATP). Эта функциональность бесплатна для пользователей NSX Distributed Firewall (DFW), в котором есть возможности отправляемых логов IDS/IPS в NDR. Теперь пользователи могут получить больше средств мониторинга сетевой активности и более эффективно и быстро реагировать на возникающие угрозы. За счет анализа логов IDS/IPS от GFW и DFW, в комбинации с функциями Network Traffic Analysis (NTA) и Sandboxing, система NDR может сопоставлять события и идентифицировать паттерны атак, предоставляя пользователю полную картину угроз, существующих в корпоративной сети.
2. Защита Windows 11
В NSX 4.1 появилась поддержка механизма NSX Guest Introspection для ОС Windows 11, что дает расширенные инструменты обнаружения угроз и борьбы с ними для виртуальных машин. Все прошлые версии Windows и Linux также продолжают поддерживаться. Guest Introspection использует тонкий драйвер-агент в составе VMware Tools, чтобы предоставлять информацию в реальном времени о состоянии виртуальных машин, чтобы наиболее эффективно принимать меры по обеспечению безопасности.
3. Улучшенная безопасность контейнеров
Теперь появились расширенные функции по защите контейнеров на базе политик с централизованным управлением правилами сетевого экрана за счет интеграции Antrea и NSX. Теперь в NSX 4.1 правила фаервола могут быть созданы для обоих объектов - Kubernetes и NSX, а динамические группы можно создавать как на базе тэгов NSX, так и на основе меток Kubernetes. Также в этом релизе можно создавать политики фаервола, которые позволяют блокировать/разрешать трафик между виртуальными машинами и Kubernetes pods в рамках одного правила. Правила фаервола могут быть также применены к эндпоинтам, которые включают объекты NSX и Kubernetes. Кроме того, в NSX 4.1 есть улучшения пользовательского интерфейса и компонента Traceflow, которые дают возможности расширенного траблшутинга и централизованного управления сетевыми политиками Kubernetes через консоль NSX.
4. Поддержка IPv6
В NSX 4.0 были добавлены функции IPv6 based Management Plane, которые поддерживали коммуникацию от внешних систем к NSX management cluster (только для Local Manager). Это включало в себя поддержку NSX Manager для двойного стека IPv4 и IPv6 во внешнем управляющем интерфейсе. В NSX 4.1 теперь появилась поддержка IPv6 для коммуникации Control-plane и Management-plane между Transport Nodes и NSX Manager. Кластер NSX manager cluster должен быть по-прежнему быть развернут в режиме dual-stack и позволяет поддерживать коммуникацию транспортных узлов (хостов ESXi и узлов Edge Nodes) через IPv4 и IPv6. Если Transport Node настроен как dual-stack, то коммуникация через IPv6 является предпочтительной.
5. Маршрутизация Inter-VRF
В этом релизе представлена более расширенная модель для VRF interconnect и route leaking. Пользователи могут настраивать маршрутизацию inter-VRF с использованием более простых рабочих процессов и средств управления путем импорта и экспорта маршрутов между объектами VRF. Клиенты облака в разных VRF получают полный контроль над своим частным пространством маршрутизации и могут принимать независимые решения по маршрутам (accept / advertise).
6. Улучшения Multi-Tenancy
В NSX 4.1 появились новые конструкты для окружений с несколькими клиентами, что позволяет более гибко выделять ресурсы и управлять операционными задачами. Enterprise Admin (Provider) может сегментировать платформу на проекты, давая разные пространства для разных клиентов, сохраняя полный контроль над окружением. Это расширение к модели потребления ресурсов позволяет пользователям NSX потреблять собственные объекты, просматривать алармы только для своих конфигураций, а также тестировать соединение между рабочими нагрузками и Traceflow.
Пользователи могут переключать контекст из одного проекта на другой на базе настроенных прав RBAC (role-based access control). Пользователи, привязанные только к конкретным проектам, сохраняют доступ только к ним. Логи можно привязать к проекту, используя функцию "Project short log id", которую можно применить к логам Gateway Firewall и Distributed Firewall.
7. Онлайн-система диагностики
В NSX 4.1 появилась Online Diagnostic System - новая возможность, которая упрощает траблшутинг и помогает автоматизировать процесс отладки. Эта система содержит предопределенные runbooks, которые содержат шаги по отладке и траблшутингу для специфических ситуаций. Данные runbooks можно вызвать через API и обрабатывать шаги отладки через CLI, API и пользовательские сценарии. Рекомендуемые действия предоставляются после отладки, чтобы дать инструменты решения проблем, а также артефакты, сгенерированные во время отладки, могут быть загружены для последующего анализа.
Более подробно о новых возможностях VMware NSX 4.1 можно почитать в Release Notes. Основная страница продукта находится вот тут.
Итак, публикуем четвертую часть нашего большого рассказа о новых возможностях главного решения для резервного копирования и репликации виртуальных машин компании Veeam - Backup & Replication v12, которое уже доступно для скачивания.
Сегодня мы поговорим о плагинах приложений, виртуальных модулях Backup Proxy, а также резервном копировании контейнеров и NAS-хранилищ.
1. Плагины приложений
Управление плагинами:
Centralized application plug-in management - мастер Protection Group был расширен дополнительными настройками для контроля над установкой и обновлениями плагинов приложений на включенных в группу серверах. Теперь есть сбор информации о топологии приложений и обнаружение систем Oracle RAC и SAP HANA при сканировании и ресканировании.
Certificate-based TLS authentication - Protection Groups теперь используют аутентификацию на базе сертификатов при установке соединения с плагинами.
Application backup policy - появилась возможность оркестрации бэкапов Oracle RMAN, SAP HANA и SAP on Oracle на базе политик из бэкап-консоли, что позволяет избавиться от ручного обслуживания конфигураций плагинов и бэкап-сценариев на каждом сервере БД.
Granular database-level protection settings - политики бэкапа приложений поддерживают различные настройки для отдельных БД. Каждая политика может быть применена к своему набору баз данных.
Centralized backup monitoring - политики бэкапа приложений имеют средство для мониторинга процесса РК на каждом сервере в реальном времени, визуализации статистики и отчетов для бэкапов баз данных и redo-логов.
Recovery tokens - бэкап-администраторы теперь могут сгенерировать временные токены для бэкап-плагинов. Они могут быть использованы для соединения с репозиториями и восстановления баз данных с помощью нативных утилит, без необходимости назначения пользователю постоянной роли.
Плагин для Microsoft SQL Server:
Новый плагин предоставляет глубокую интеграцию с Microsoft SQL Server (VDI-плагин), что позволяет делать прямой бэкап напрямую в репозитории Veeam.
VDI-плагин использует нативные средства для обеспечения консистентности бэкапов, и, в отличие от бэкапов на базе снапшотов, не завязан на Microsoft VSS, что позволяет делать резервные копии разных конфигураций SQL Server, таких как Windows Server Failover Clusters с томами shared volumes. Теперь плагин может защитить до 2000 баз данных на один SQL-сервер и до 10000 БД на бэкап-сервер.
Плагин был полностью переработан, чтобы защищать разные конфигурации SQL Server, такие как SQL Always On, где задачи РК автоматически считывают данные с предпочитаемого сервера реплики.
Теперь интерфейс плагина полностью интегрирован с Microsoft SQL Server Management Studio, где он может быть запущен по клику на иконку в тулбаре. Также стандартный бэкап баз данных на репозитории Veeam полностью поддерживается. Сам же плагин может создавать задачи SQL Server Agent прямо из графического интерфейса.
Задачи Backup Copy поддерживают нативные бэкапы SQL на вторичные репозитории, а если вы хотите избежать управления этими дополнительными задачами, то можно использовать SOBR для Capacity Tier в режиме Copy mode.
Анализ цепочек бэкапов позволяет разгрузить процедуру РК за счет перемещения неактивных бэкапов с помощью политики Move policy для освобождения дискового пространства на Performance Tier, а также убедиться, что период immutability корректно пролонгирован для активных цепочек бэкапов.
Плагины для Oracle RMAN и SAP HANA:
Performance improvements — в V12 до 3х увеличена скорость резервного копирования и восстановления. Это было сделано за счет улучшений data movers, которые забирают данные напрямую из приложения, минуя промежуточный процесс plug-in manager.
Reduced impact on production environment - теперь не нужно запускать выделенный data mover для каждого backup channel, что уменьшает количество муверов, которые запущены на сервере БД. Планировщик следит за тем, чтобы дата муверов было не более, чем в два раза больше, чем доступных ядер CPU.
Linux ACL support for configuration files - можно использовать группы в Linux для запрета изменений конфигурации плагина бэкап-операторами.
2. Виртуальные модули Backup Proxy
Veeam Backup for AWS - здесь добавлены immutable-бэкапы инстансов EC2 для хранилищ AWS S3, улучшения масштабируемости для больших окружений, поддержка GP3-дисков для виртуального модуля, поддержка multi-tenant контейнера для Oracle, поддержка OAuth 2.0 для email-нотификаций, интеграция с Veeam Service Provider Console и поддержка Veeam Universal License (VUL), а также другие возможности.
Veeam Backup for Microsoft Azure - тут была добавлена поддержка immutable-бэкапов для Azure VM и Azure SQL в хранилище Azure Blob storage, улучшения масштабируемости для больших окружений, контроль нагрузки для репозиториев, поддержка OAuth 2.0 для email-нотификаций, интеграция с Veeam Service Provider Console и поддержка Veeam Universal License (VUL), а также другие возможности.
Veeam Backup for Google Cloud - тут была добавлена гранулярная защита для баз данных PostgreSQL, возможность хранить снапшоты инстансов в одном регионе, улучшены средства управления для cross-project service accounts, добавлена возможность использовать папки организации как источник политик, а также реализована поддержка Veeam Universal License (VUL).
Veeam Backup for Nutanix AHV - переработан интерфейс, добавлена возможность прямого бэкапа в object storage, поддержка immutable и synthetic full бэкапов, политики хранения GFS, защита от повреждения хранилищ, REST API для управления бэкапом и восстановлением. Также увеличена производительность и добавлена поддержка Instant VM Recovery из репозиториев Veeam Cloud Connect.
Veeam Backup for Red Hat Virtualization (RHV) - добавлена возможность прямого бэкапа в object storage, поддержка immutable и synthetic full бэкапов, политики хранения GFS, защита от повреждения хранилищ и сделано множество улучшений интерфейса.
3. Резервное копирование контейнеров
Kasten K10 Backup for Kubernetes integration - инстансы K10 теперь могут быть зарегистрированы на бэкап-сервере, что позволяет просмотреть все политики РК для Kubernetes, а также сессии и бэкапы напрямую из backup console, вне зависимости от того, хранятся ли они в репозиториях Veeam или в другом месте. Вызов редактирования политик и операций по восстановлению перенаправляет пользователя в контекстный рабочий процесс K10 и позволяет завершить его через K10 web UI.
4. Резервное копирование NAS-хранилищ
Общие улучшения:
SMB over QUIC support - теперь задачи РК файловых шар могут получать данные по SMB более безопасно и эффективно через протокол QUIC.
Recovery throttling support - при восстановлении бэкапов можно управлять загрузкой сетевого канала.
Improved search performance - новая функциональность поиска работает на 25% быстрее, как в backup console, так и в Veeam Backup Enterprise Manager web UI.
Storage-level corruption guard enhancements - теперь проверка состояния процессов включает в себя оповещения пользователя о возможных проблемах с архивированными метаданными.
NFS fs_locations support - теперь бэкап файловых шар понимает концепцию NFS referrals, что позволяет организовать защиту более комплексных распределенных файловых систем NFS.
Бэкап на диск:
Copy mode - в дополнение к архивированию старых версий файлов, которые не включены в политику хранения бэкапов, теперь есть опция заархивировать также и текущие версии. В этом случае архив будет содержать полную копию бэкапа, для которого будет доступно полное восстановление файловой шары к последнему состоянию напрямую из архивного репозитория.
Expanded exclusion rules - теперь можно исключить отдельные шары из копирования в виде \share\folder\path, добавив путь для правил исключений. В этих правилах можно использовать астериски вида *\folder (поддерживается только для одного уровня папок). Также по умолчанию из процессинга исключаются папки \ipc$, \admin$ и \c$ (это можно изменить).
Advanced backup mapping - теперь можно избежать полного бэкапа в случае переименования файловой шары с помощью PowerShell командлета Update-VBRNasBackupPath.
Бэкап на ленточные носители:
Scalable file backup engine - теперь при большом количестве файлов они объединяются в файлы образов в целях более быстрой записи на ленточные носители.
NAS backup to tape - теперь бэкапы файловых шар можно использовать как источник для задач резервного копирования на ленту в рамках подхода Disk to Disk to Tape (D2D2T). Так как это вторичный бэкап - он не требует отдельной лицензии.
Функции Instant Recovery:
Writable SMB file shares - эмулируемые SMB-шары, которые публиковались как часть instant file share recovery теперь доступны на запись, что позволяет пользователям продолжать работать с шарой в обычном режиме, включая процессы изменения существующих файлов и создания новых. Сами NAS-бэкапы не изменяются и все изменения кэшируются отдельно.
Migration to production - как только ваше хранилище NAS возвращается в онлайн, вы можете инициировать процесс восстановления самого последнего ее состояния из бэкапа. Эта операция выполняется в фоновом режиме без необходимости пользователя взаимодействовать с опубликованной файловой шарой.
Switchover - теперь есть три опции переключения восстановления для финализации instant recovery: Automatic (фоновый процесс), Scheduled (возможность отложить переключение на часы наименьшей нагрузки) и Manual (интерактивный ручной процесс). На время финализации этих процессов файловая шара будет недоступна.
Публикация:
NFS shares publishing - защищенные шары теперь могут быть опубликованы напрямую из бэкапа как эмулируемые SMB-шары. Это может быть, например, полезно для работы аналитического ПО, которое использует в качестве источника хранимые там данные.
Интеграции с файлерами:
Nutanix Filers integration - теперь можно зарегистрировать файлеры Nutanix Files в качестве источника и выполнять бэкап файлов без необходимости получать доступ к каждой защищенной файловой шаре. В этом случае бэкапы будут выполняться из нативных снапшотов хранилища, что позволяет избежать проблем с заблокированными файлами. Кроме того, бэкап теперь работает существенно быстрее благодаря поддержке технологии Nutanix Files Changed File Tracking (CFT).
Dell PowerScale (Isilon) - теперь появилась поддержка OneFS версий 9.3 и 9.4 для нативной интеграции файлеров в процесс резервного копирования.
Интеграции с хранилищами:
Rotated drive support - бэкапы файловых шар теперь поддерживают репозитории на основе ротируемых носителей.
AWS Snowball Edge support - в дополнение к поддержке Microsoft Azure Data Box теперь есть и поддержка первоначального бэкапа средствами объектного хранилища AWS Snowball Edge для последующего импорта в соответствующее публичное облако.
Ну, для четвертой части пока хватит новых фич) В следующих статьях мы продолжим рассматривать другие новые функции Veeam Backup & Replication v12, которых очень много появилось в этом большом релизе. Скачать пробную версию продукта можно бесплатно по этой ссылке.
Сам гипервизор ESXi присутствует на рынке уже более 15 лет (раньше он назывался ESX и был построен поверх ОС Linux), и его состав и занимаемый объем на диске менялся со временем. Напомним, что в восьмой версии гипервизора VMware добавила компоненты esxio, обеспечивающие функционирование технологии Project Monterey и SmartNIC, а также составляющие поддержки архитектуры ARM.
Давайте посмотрим, как менялся объем гипервизора, входившего в установочный ISO-образ ESXi, от версии к версии:
ESXi 3.5 - 46,01 MB
ESXi 4.0 - 59,99 MB
ESXi 4.1 - 85,19 MB
ESXi 5.0 - 132,75 MB
ESXi 5.1 - 125,85 MB
ESXi 5.5 - 151,98 MB
ESXi 6.0 - 154,90 MB
ESXi 6.5 - 135,39 MB
ESXi 6.7 - 129,51 MB
ESXi 7.0 - 149,40 MB
ESXi 8.0 - 226,62 MB
Визуализация этих цифр выгладит так:
Надо сказать, что это только размер самого гипервизора, но помимо него в установочном образе содержатся и другие элементы, такие как драйверы устройств, образы VMware Tools и другие вспомогательные библиотеки и системные компоненты.
Если посмотреть на ISO-образ VMware ESXi 8.0, то там будут следующие составные части:
Визуализация этого выглядит так:
Сейчас установочный ISO-образ весит 600-650 МБ, в зависимости от содержащихся в нем апдейтов:
Также если вы перейдете на страницу загрузки VMware ESXi, то увидите, что там есть и Offline Bundle, который занимает значительно больше места на диске, а поставляется он в формате ZIP-архива:
Этот бандл нужен в качестве источника для обновлений VMware Lifecycle Manager - он содержит не только сами компоненты ISO-образа, но и все необходимые апдейты, которые можно накатить на уже установленный гипервизор, чтобы получить актуальную версию платформы.
И снова продолжаем рассказывать о новых возможностях главного решения для резервного копирования и репликации виртуальных машин компании Veeam - Backup & Replication v12, которое уже доступно для скачивания.
Ну а сегодня мы напишем о том, что нового в 12-й версии в части резервного копирования и восстановления на уровне образов, функций Continuous Data Protection (CDP), а также новых агентов Veeam Agent.
1. Резервное копирование на уровне образов
Функции Application-aware processing:
PostgreSQL support - теперь поддерживается application-aware бэкап транзакционных логов для point-in-time восстановлений баз данных PostgreSQL на Linux. Такая же функциональность уже была ранее для СУБД Microsoft SQL Server и Oracle.
Persistent guest agent enhancements - если у вас нет прямого сетевого соединения, то guest interaction прокси будут взаимодействовать с агентом гостевой ОС через протоколы VIX и PSDirect, не требующие сетевого соединения.
Планировщик резервного копирования:
More synthetic full scheduling options - теперь в дополнение к недельным полным синтетическим бэкапам можно делать и ежемесячные резервные копии такого типа (однако вам потребуются block cloning aware репозитории на базе быстрых носителей).
More monthly GFS scheduling options - теперь ежемесячные GFS бэкапы могут быть запланированы на 1/2/3/4 и последнюю неделю месяца. Эту опцию можно использовать для распределения нагрузки задач по старым/медленным репозиториям без поддержки block cloning.
Increased GFS restore point limits - теперь политики хранения копий GFS расширены до 9999 недель. Удивительно, но некоторым пользователям не хватает 999 недель.
Функции Backup Copy:
Per-machine backup chains - теперь новые задачи Backup Copy создают цепочки в новом формате на базе отдельных ВМ, чтобы обеспечить совместимость с новым функционалом платформы. Существующие задачи не будут затронуты этим обновлением.
Expanded platform support - теперь можно копировать бэкапы, которые были созданы задачами на базе агентов в режиме Managed-by-Agent, бэкапы, созданные в репозиториях Veeam отдельными агентами, а также бэкапы, созданные Veeam Backup for Nutanix AHV и Veeam Backup for Red Hat Virtualization. Это включает в себя и бэкапы транзакционных логов, созданные этими задачами (только в режиме Immediate copy).
Ability to change backup copy mode - все новые задачи Backup Copy поддерживают изменение типа с Immediate на Periodic и обратно в любое время.
Active full for GFS restore points - теперь точки восстановления GFS создаются в активном режиме, то есть информация о точке восстановления читается из исходного бэкапа (в том числе, и для режима Immediate copy). Ранее эти данные синтезировались из точек восстановления GFS для существующих данных в репозитории.
Restore point selection option - теперь с помощью улучшенных задач Periodic Backup Copy вы можете указать, хотите ли вы подождать, пока исходная задача финализирует точку восстановления, которая сейчас создается, либо выбрать вместо этого последнюю доступную точку восстановления.
Daily email reporting option - вы можете теперь получать отчет раз в день с саммари всех выполненных задач, либо продолжить получать отчеты по завершении каждой задачи.
Функции SureBackup:
Agent-based backup support - в дополнение к host-based бэкапам ВМ на VMware и Hyper-V, задачи SureBackup теперь поддерживают процессинг бэкапов на базе агентов для облачных, физических и виртуальных машин Windows и Linux.
Multi-platform jobs and application groups - начиная с V12, задачи SureBackup и Application Groups теперь могут содержать несколько платформ, то есть микс из бэкапов VMware, Hyper-V и на базе агентов. Обработанные машины будут сконвертированы в платформу виртуальной лаборатории (VMware или Hyper-V) через процесс P2V/V2V на лету.
Disable Windows Firewall - для Application Groups теперь есть опция по автоматическому отключению сетевого экрана Windows Firewall, перед там как запустить их в виртуальной тестовой лаборатории. Это нужно для тех бэкапов, для тестирования восстановления которых требуется, чтобы фаервол не блокировал внешние соединения.
Гранулярные нотификации по почте - так же, как и для бэкапов, для процесса SureBackup вы можете установить нотификации для отдельных задач, что будет иметь приоритет над глобальными настройками.
2. Восстановление из бэкапов на уровне образов
Восстановление объектов приложений:
Application item-level recovery Veeam Explorer for PostgreSQL - новый продукт в семействе Veeam Explorer позволяет восстанавливать инстансы без необходимости наличия опыта работы администратора с PostgreSQL. Также можно опубликовать любое состояние point-in-time инстанса напрямую из бэкапа в заданный Dev/Test-сервер, после чего внесенные изменения в опубликованной БД могут быть экспортированы или отменены.
Veeam Explorer for Microsoft SQL bulk restore - теперь можно выбрать несколько баз данных при выполнении массового экспорта, восстановления или Instant Recovery. В этом случае Veeam Explorer автоматически создаст и запустит несколько задач - по одной на каждую БД.
Восстановление на уровне файлов для Windows:
Compare with production - теперь можно сравнить точку восстановления с файлами работающей продакшен-машин с помощью обновленного Backup Browser, что дает понять, какие файлы были изменены или удалены с момента снятия выбранной резервной копии.
Restore changes only - этот новый режим восстановления позволяет вам быстро начать восстановление только тех файлов, которые были изменены или удалены с момента снятия выбранного бэкапа, что уменьшает время восстановления после атак ransomware или пользовательской ошибки.
Compare attributes - возможность проверить на одном экране различия в атрибутах отдельных файлов и папок от таковых в продакшен-системе с помощью нового диалогового окна.
Restore permissions only - возможность восстановить только разрешения для файлов и папок (access control lists, ACL). Это может понадобиться, когда администратор случайно массово изменил права на папки и файлы.
Restore directly to another machine - возможность выбрать другую целевую машину для прямого восстановления файлов Windows (ранее было доступно только для Linux).
Alternate Data Streams (ADS) restore - при восстановлении файлов и папок для бэкапа с томов NTFS также на том NTFS происходит и восстановление контента ADS.
ReFS volume autodetection - V12 автоматически обнаруживает тома ReFS в бэкапах и монтирует их через VHD mount API. Это предотвращает выпадение в BSOD при определенных комбинациях сервера и защищаемой ОС.
Восстановление на уровне файлов для Linux:
Restore from storage snapshots without a helper appliance - восстановление файлов из снапшотов хранилищ для ОС Linux теперь может монтировать бэкапы к любой Linux-машине (той же куда нужно восстанавливать или любой другой, например, той, которая лучше понимает файловую систему восстанавливаемого бэкапа).
FLR helper appliance improvements - теперь можно указать DNS-сервер для helper appliance, чтобы разрешение имен проходило всегда корректно.
Функции Instant VM Recovery:
Instant VM Recovery to Hyper-V without space pre-allocation — при выполнении мгновенного восстановления любого бэкапа в ВМ на Microsoft Hyper-V теперь у вас есть опция не преаллоцировать дисковое место для восстановления заранее. Это ускоряет процесс начала восстановления.
Функции Secure Restore:
Bitdefender support — в V12 добавлена out-of-the-box интеграция с антивирусом Bitdefender.
Экспорт бэкапов:
Export backups to another location - теперь улучшенная функциональность Export Backup позволяет выбрать любое назначение для экспортируемой точки, а не только тот же репозиторий, где находился исходный бэкап.
Export as a virtual disk enhancement - теперь экспорт в виртуальный диск доступен не только для agent-based бэкапов, но и для host-based.
3. Улучшения Continuous Data Protection (CDP)
CDP proxy on Linux - теперь прокси CDP может работать на Linux-сервере.
Veeam Cloud Connect support - в дополнение к регулярным задачам РК, вы можете использовать любой облачный хост сервис-провайдера для выполнения репликации в рамках политик CDP.
VMware Cloud Director support - теперь вы можете использовать репликацию в рамках инстансов Cloud Director с функциями мгновенного восстановления к нужной точке для ВМ и модулей vApps.
Enhanced security - коммуникация между всеми компонентами CDP теперь защищена протоколом TLS.
Support for native VVOL snapshots - теперь обеспечивается нативная поддержка снапшотов VVOL, что уменьшает число хранимых там объектов и увеличивает надежность на устройствах, у которых небольшие лимиты по масштабируемости томов VVOL.
Sparse block detection - дисковые блоки Sparse теперь пропускаются при первоначальной инициализации репликации, что увеличивает производительность.
Improved transaction log storage formats - теперь транзакционные логи хранятся как виртуальные диски, а не файлы, что существенно увеличивает скорость записи на них.
Proxy memory overflow protection - возникшая проблема с репликацией отдельного диска теперь больше не влияет на процессинг других дисков на этом же прокси.
4. Улучшения агентов
Управление агентами:
Agent Management Recovery tokens - теперь администраторы могут сгенерировать временные ключи доступа или токены восстановления, которые можно дать пользователям для задач восстановления Bare Metal Recovery.
Changed-block tracking for Windows workstations - в дополнение к Windows Server, мастер Protection Group теперь имеет опцию по установке драйвера Veeam changed block tracking (CBT) на рабочие станции с Windows 10 или более поздние для более быстрого инкрементального копирования.
Multiple cluster volume recovery - теперь несколько томов восстанавливаются на кластерный диск одновременно, что уменьшает время восстановления.
Также были обновлены следующие агенты:
Veeam Agent for Microsoft Windows - новая функциональность включает в себя: прямой бэкап в object storage, новая БД конфигурации на базе SQLite, файловые бэкапы на базе CBT для серверов и рабочих станций, поддержка OAuth 2.0 для нотификаций по почте, поддержка последних версий Windows и другое.
Veeam Agent for Linux - добавлен функционал advanced data fetcher, прямой бэкап в object storage, политики хранения GFS, поддержка последних дистрибутивов Linux и другое.
Veeam Agent for Mac - новый графический интерфейс, прямой бэкап в object storage, возможность продолжения приостановленного бэкапа, нативная поддержка чипов M1 и M2, FIPS compliance, поддержка последних версий macOS и другое.
Veeam Agent for AIX - функция Bare Metal Recovery с полностью автоматическим маппингом дисков в систему.
Veeam Agent for Solaris - функция Bare Metal Recovery с полностью автоматическим маппингом дисков в систему.
На этом пока все. В следующих статьях мы продолжим рассматривать другие новые функции Veeam Backup & Replication v12, которых очень много появилось в этом большом релизе. Скачать пробную версию продукта можно бесплатно по этой ссылке.
Не все ИТ-администраторы знают, что у компании VMware есть программа
Guru Licensing Program, предназначенная для ИТ-специалистов, которые ориентированы на различное корпоративное ПО, работающее в инфраструктурах виртуализации и облаках, но напрямую не связаны с продуктами для виртуализации от VMware.
Сразу оговоримся, что политика компании VMware в данный момент запрещает участие в программе лицам, живущим на территории России и Беларуси. Это относится только к резидентам этих стран, но не касается их граждан, живущих за их пределами на постоянной основе (недавно этот факт подтвердили руководители других программ, в частности, VMware vExpert).
Итак, Guru Licensing Program ориентирована на лидеров различных комьюнити (Community Champions, Leaders и Technologies Experts), которые имеют сертификации других вендоров и активно принимают участие в публичных дискуссиях, задевая по касательной технологии VMware.
В частности, имеются в виду профессионалы, имеющие следующие активные сертификации и награды:
Чтобы принять участие в программе VMware Guru Licensing Program, нужно просто отправить письмо по этому адресу, и в ответ вы получите форму, после заполнения которой вас допустят к ее преимуществам. Также письмо отправить могут все участники VMware Database Experts Workshop.
Заявки в программу принимаются 2 раза в год - в марте и в сентябре. В этом году весенний прием заявок будет с 6 по 31 марта.
Network-less discovery and deployment - теперь обнаружение новых рабочих нагрузок и автоматических развертываний бэкап-агентов происходит через нативный cloud API без прямого подключения к защищенным машинам.
Dynamic protection scope - теперь так же, как вы защищаете несколько онпремизных машин, указывая контейнеры и тэги, по которым происходит добавление в группу, можно создавать и Protection Groups для облачных ВМ через аналогичные конструкты в публичном облаке.
In-cloud data flow - теперь можно бэкапить ВМ в хранилища object storage того же облачного провайдера, без путешествия трафика РК через интернет, что позволяет снизить затраты на внешний трафик.
Full portability - теперь любые результирующие облачные бэкапы ВМ можно восстановить в любое целевое облако или на онпремизную площадку.
2. Функции платформы
PostgreSQL support for a configuration database - теперь поддерживается мультиплатформенный движок PostgreSQL, что позволяет избежать ограничений Microsoft SQL Server Express Edition на размер базы в 10 ГБ. Сам SQL Server Express Edition продолжает поддерживаться, но уже не включен в состав продукта Veeam Backup and Replication. Вот так база PostgreSQL выглядит в PGAdmin:
3. Движок резервного копирования
New backup chain metadata format - новый формат метаданных на уровне ВМ позволяет более удобно и гранулярно управлять функциями защиты бэкапов. Например, можно выполнять операции Active Full или Retry для отдельных машин, а не на уровне всей задачи. Также различные операции с компонентами задач теперь работают быстрее, так как не ждут завершения всей задачи.
Policy-like jobs - теперь версия V12 сочетает в себе функции управления на базе задач и функции управления на базе политик. Можно создавать очень большие задачи с тысячами машин, перемещать бэкапы между задачами и выполнять прочие действия, которые работают по аналогии с таковыми в стиле политик защиты данных.
Background retention - ранее функции автоматической ротации и удаления старых копий работали для GFS-хранилищ, а сейчас они доступны вообще для всех бэкапов (в том числе для отключенных задач, с использованием их последней активной retention policy). Этот процесс автоматически запускается в полночь, но может быть и запущен вручную.
4. Управление данными бэкапов
VeeaMover - это новый движок перемещения данных между репозиториями различных типов. Теперь вам не нужно думать о типе исходного и целевого репозитория - VeeaMover автоматически сделает всю работу по перемещению данных.
Block clone awareness - теперь при клонировании ВМ на уровне блоков для ReFS/XFS/object storage при миграциях происходит существенная экономия дискового пространства по аналогии с перемещением файлов бэкапа с хранилищ SMB на XFS.
Streamlined repository change processes - теперь можно переместить все данные репозитория в другое место с помощью VeeaMover и далее просто сделать его апгрейд.
Move backups between jobs - теперь бэкапы можно просто перемещать между задачами и все сопутствующие операции будут выполнены автоматически (например, работа со списками inclusion и exclusion).
Copy backups between repositories - теперь всю цепочку бэкапов можно переместить в другое место в несколько кликов, при этом политика retention policy сохранится (но можно и изменить ее).
5. Инфраструктура резервного копирования
Работа с репозиториями:
Multiple gateway server support - в дополнение к автоматическому выбору шлюза вы теперь можете указать пул шлюзовых серверов, который вы хотите использовать для передачи данных от/к определенному бэкап-репозиторию. Шлюзы в рамках пула приоритизируются по скорости соединения и текущей нагрузке по задачам. Использование нескольких шлюзов полезно при использовании конфигураций хранилищ Fibre Channel (FC) для обеспечения избыточности каналов передачи данных и необходимого уровня производительности.
Rotated drives cleanup - теперь при переключении на ротируемые носители происходит автоматическая очистка дисков от существующих там старых бэкапов. Пользователи также могут продолжить использование существующей цепочки бэкапов, а также выбрать один из двух вариантов: удалить бэкапы, которые относятся только к текущей задаче, либо удалить все бэкапы на носителе.
Функции Scale-out Backup Repository (SOBR):
Object storage as performance extent - теперь Performance Tier может использовать экстенты object storage в дополнение к экстентам блочных и файловых хранилищ.
Support for multiple object storage extents - Performance Tier и Capacity Tier могут использовать несколько экстентов object storage. Это полезно, когда объектное хранилище поддерживает ограниченное число объектов на узел. В этом случае для дополнительных экстентов будет использоваться балансировка round-robin на уровне ВМ.
Direct to archive - при использовании AWS S3 или Microsoft Azure Blob Storage как экстентов вы можете пропустить настройку Capacity Tier. В этом случае бэкапы будут сразу перемещаться из Performance Tier на Archive Tier.
Glacier Instant Retrieval support - в этом обновлении была добавлена поддержка класса хранилищ Glacier в качестве Archive Tier. В этом случае производительность будет обеспечиваться на уровне классов хранилищ S3 Standard и S3 Standard-IA, чтобы быстро получить доступ к архивным резервным копиям.
SOBR rebalance - теперь можно выполнить ребалансировку потребления хранилищ на уровне блочных и файловых хранилищ для экстентов Performance Tier, чтобы выровнять распределение данных между ними. Эту операцию нужно выполнять тогда, когда вы хотите добавить новый экстент, постоянно выполнять ее не нужно.
VeeaMover integration - операции Extent evacuation и SOBR rebalance используют новый движок VeeaMover, чтобы более эффективно перемещать бэкапы между экстентами.
Strict data placement policy enforcement - по умолчанию SOBR мог нарушать политику размещения данных, чтобы убедиться, что бэкап был записан на носитель. Теперь же можно включить опцию, когда в этом случае задача РК завершится с ошибкой.
Функции управления трафиком:
Support for multiple internet rules - теперь по просьбе пользователей добавлены несколько интернет-правил для управления трафиком в окружениях с несколькими площадками и сетями.
Time-based throttling level - теперь есть более гибкие функции по регулированию использования канала, в зависимости от времени дня, чтобы не создавать большую нагрузку на инфраструктуру. Теперь есть настройка Unthrottle для различных регуляций трафика в часы наименьшей нагрузки.
Restore traffic throttling options - теперь правила регулирования трафика распространяются и на процессы восстановления, а не только на процесс резервного копирования.
Нотификации по электронной почте:
OAuth 2.0 support for email notifications - теперь в дополнение к аутентификации через SMTP продукт поддерживает и авторизацию через протокол OAuth в Google Gmail и Microsoft 365.
Active instant recoveries - теперь ежедневные отчеты напомнят пользователю обо всех активных сессиях Instant Recovery, которые еще не завершились.
Full product version display - отчеты теперь включают в себя полную версию сервера, включая уровень патча.
Поддержка VMware vSphere:
VMware vSphere Linux backup proxy enhancements - теперь появилась поддержка прямого доступа к хранилищу для режима транспорта, которая позволяет прокси на базе Linux выполнять прямое резервное копирование из снапшотов NFS-хранилищ.
Hardened repository as a backup proxy - теперь можно использовать защищенный репозиторий как бэкап-прокси в режиме NBD. В этом случае недоступны функции режимов Advanced transport, так как они требуют доступа root, что небезопасно.
Improved replication performance - виртуальные машины со снапшотами SeSparse (на хранилищах VMFS-6) будут реплицироваться быстрее, так как их копирование будет проходить в асинхронном режиме.
Backup I/O control latency minimums - учитывая новые хранилища All-Flash настройки latency теперь можно регулировать на уровне миллисекунд.
Поддержка Microsoft Hyper-V:
Infrastructure caching - так же, как и для vSphere, бэкап-сервер теперь кэширует информацию хостов Hyper-V для уменьшения запросов через интерфейс WMI. Это увеличивает производительность задач РК и отклик интерфейса консоли в больших инфраструктурах.
Compatibility checker enhancements - теперь можно восстанавливать и реплицировать ВМ на хосты Hyper-V меньшей версии, чем изначальные, если там поддерживается соответствующая версия VM hardware.
В следующих статьях мы продолжим рассматривать другие новые функции Veeam Backup & Replication v12, которых очень много появилось в этом большом релизе. Скачать пробную версию продукта можно бесплатно по этой ссылке.
При попытке запустить такую ВМ она не включится, а в логе vmware.log в папке с ВМ вы увидите такие записи:
2023-02-15T05:34:31.379Z In(05) vcpu-0 - SECUREBOOT: Signature: 0 in db, 0 in dbx, 1 unrecognized, 0 unsupported alg.
2023-02-15T05:34:31.379Z In(05) vcpu-0 - Hash: 0 in db, 0 in dbx.
2023-02-15T05:34:31.379Z In(05) vcpu-0 - SECUREBOOT: Image DENIED.
Ситуация была исправлена со стороны VMware в патче обновлений vSphere 7 Update 3k (KB 90947), который предлагается установить всем пользователям, затронутых этой ситуацией.
Отметим, что с виртуальными машинами на vSphere 8 никаких неприятностей не произошло.
Скачать VMware vSphere 7 Update 3k можно по этой ссылке. Release Notes находятся тут.
Компания VMware выпустила небольшое обновление хост-серверов платформы виртуализации VMware vSphere - ESXi 8.0b и vCenter 8.0b. Напомним, что о прошлом обновлении VMware vCenter 8.0a мы писали вот тут.
Из нового в ESXi 8.0b заявлена только поддержка технологиии vSphere Quick Boot для следующих серверов:
Наш постоянный читатель Сергей обратил внимание на то, что недавно вышла новая версия средства мониторинга ИТ-инфраструктуры Zabbix 6.2, в которой есть много всего нового и полезного для наблюдения за виртуальной инфраструктурой VMware vSphere.
Давайте посмотрим, что там интересного в плане работы с хостами vSphere:
Возможность вручную назначать шаблоны обнаруженным хостам ESXi
Создание и изменение пользовательских макросов для обнаруженных хостов ESXi
Добавление дополнительных тэгов для серверов
Также функции мониторинга были доработаны, чтобы поддерживать новые сущности и низкоуровневые правила их обнаружения.
Это позволяет отслеживать новые метрики, а именно:
Также теперь обнаружение хостов VMware vSphere может быть отфильтровано на базе их статуса включенности (например, можно добавить только работающие сейчас хосты ESXi).
Более подробно о новой версии Zabbix 6.2 можно почитать на этой странице. Скачать продукт можно тут.
Недавно компания Veeam Software, главный производитель средств для резервного копирования и защиты данных виртуальных инфраструктур, анонсировала выпуск новой версии Veeam Backup & Replication v12. Ну а на днях финальная версия этого продукта стала доступной для скачивания. Давайте посмотрим, что там появилось нового в части прямого резервного копирования в объектные хранилища, неизменяемых бэкапов и безопасности.
Новые возможности сгруппированы по категориям. Это одно из самых насыщенных обновлений продукта, поэтому мы решили разбить рассказ о новых возможностях на несколько статей. Итак:
1. Прямое резервное копирование в объектное хранилище
Direct-to-Object - теперь данные бэкапов передаются напрямую из бэкап-прокси и агентов в объектное хранилище, минуя промежуточные шаги. Также, если прямое соединение с таким хранилищем недоступно, то можно перенаправить трафик через отказоустойчивый пул серверов-шлюзов.
Direct-to-Cloud - в новой версии доступно более эффективное прямое резервное копирование в облако, в том числе из окружений Remote Office Branch Office (ROBO). По-прежнему, Veeam рекомендует иметь также и локальные резервные копии у себя в датацентре в рамках правила 3-2-1 (3 копии данных, 2 разных носителя, 1 облачная копия вне площадки).
Immutable backups - функция неизменяемости резервных копий (даже со стороны администратора), которая доступна в локальных и облачных окружениях). Это позволяет избежать шифрования бэкапов со стороны вредоносного ПО (Ransomware). Такие резервные копии защищаются в течение всего своего жизненного цикла хранения.
Spaceless full backups - это репозитории на базе файловых систем ReFS и XFS, когда бэкапы записываются напрямую в объектное хранилище. Такой бэкап не потребляет дополнительного дискового места, кроме непосредственно основных хранимых данных.
Improved storage format - теперь формат хранения данных бэкапов существенно оптимизирован, в том числе теперь нет необходимости в синхронизации локальных и облачных индексов.
Health check light - теперь задачи, управляемые агентами и использующие объектные хранилища, могут быть полностью просканированы на возможные повреждения данных. Это сканирование проводится только по мере необходимости, что не нагружает инфраструктуру, но пользователь может самостоятельно запустить полное сканирование.
Wasabi integration - теперь Wasabi входит в число партнеров в области облачных объектных хранилищ, для чего теперь есть отдельный пользователь интерфейс для доступа к репозиторию Wasabi Hot Cloud Storage.
Smart Object Storage API - это новый программный интерфейс (SOSAPI), который позволяет вендорам объектных хранилищ глубоко интегрироваться с решением Veeam Backup & Replication v12 для лучшей производительности и качества пользовательского опыта. Например, можно направить бэкап конкретной машины на специфический бэкап-узел для более быстрого бэкапа. SOSAPI-интеграции могут использовать функции Scality (программные хранилища) и Object First (аппаратные модули).
2. Расширенные функции immutability
Immutability for more backup types - теперь в дополнение к поддержке бэкапов на уровне образов функции неизменяемости резервных копий доступны и для NAS-хранилищ, standalone-агентов, бэкапов в AWS и Microsoft Azure, а также для транзакционных логов и enterprise-приложений через плагины.
Hardened repository improvements - теперь для апгрейдов компонентов защищенных репозиториев не требуется соединение с сервером по SSH. Это упрощает управление инфраструктурой репозиториев и позволяет не думать об их дополнительной защите. Также теперь в интерфейсе Veeam B&R есть специальный мастер для защищенной конфигурации, а также есть специальный тип защищенного репозитория, в который можно сконвертировать существующие в автоматическом режиме.
Microsoft Azure Blob Storage immutability support — теперь есть поддержка неизменяемых бэкапов для Blob-хранилищ. Она пока не работает для Managed-by-Agent задач ввиду ограничений Azure API, а также для репозиториев Veeam Cloud Connect, когда они работают в режиме direct transfer mode (без шлюзовых серверов).
HPE StoreOnce immutability support - в 12-й версии поддерживается создание неизменяемых бэкапов на хранилищах Catalyst Stores, где эта функция контролируется со стороны сервис-провайдера.
3. Безопасность и аудит
Multi-factor authentication - теперь доступ к консоли возможен через функцию two-factor authentication (2FA), который основан на механике одноразовых кодов Time-Based One-Time Passwords (TOTP) в соответствии с RFC 6238. Это можно включить для отдельных аккаунтов.
Kerberos-only authentication - теперь V12 можно развернуть в окружениях, где аутентификация NTLM отключена в целях повышенной безопасности. Аутентификация Kerberos поддерживается для всех компонентов инфраструктуры резервного копирования прямо из коробки. Машины можно регистрировать по DNS-именам (для Kerberos не поддерживаются IP-адреса). Для NFS хранилищ вам потребуется дополнительная конфигурация (см. User Guide).
IPv6 support - теперь поддержка IPv6 доступна для всех типов сетей (IPv6-only и dual-stack), что позволяет постепенно переходить на IPv6.
gMSA accounts for Windows - теперь для гостевых ОС Windows доступен application-aware процессинг через беспарольные аккаунты Group Managed Service Accounts (gMSA), чтобы не хранить пароли в конфигурации бэкап-серверов.
Single-use credentials for Linux - теперь для гостевых ОС Linux восстановление и управление процессом резервного копирования может быть настроено на базе сертификатов, без необходимости хранить пароли в конфигурации сервера. После этой настройки можно отключить и SSH.
Improved audit logs and alerts - в Windows Event Log и в логи аудита было добавлено более 90 дополнительных событий, включая различные задачи, выполняемые администратором. Если в лог не получается добавить запись - то сервер отправляет алерт как SNMP trap.
Automatic console lockouts - теперь есть настраиваемая блокировка консоли для простаивающих сессий.
Best practices analyzer - теперь этот компонент проверяет бэкап-сервер и конфигурацию продукта, после чего предлагает важные изменения, которые могут улучшить безопасность и шансы на удачное восстановление.
В следующих статьях мы рассмотрим другие новые функции Veeam Backup & Replication v12, которых очень много появилось в этом большом релизе. Скачать пробную версию продукта можно бесплатно по этой ссылке.
Многие пользователи уже применяют новую версию платформы виртуализации VMware vSphere 8 в своих производственных средах. Как обычно, после обновления платформы обновляется и сертификация VMware Certified Professional (VCP), которая теперь доступна в варианте для vSphere 8.x в рамках трека Datacenter Virtualization (VCP-DCV 2023).
Сам экзамен по vSphere 8 доступен по этой ссылке, где вы можете выбрать удобное вам время для сдачи. Экзамен, само собой, доступен на английском языке и за пределами России. Вот основные его разделы:
Section 1 – Architecture and Technologies
Section 2 – Products and Solutions
Section 3 – Planning and Designing
Section 4 – Installing, Configuring, and Setup
Section 5 – Performance-tuning, Optimization, and Upgrades
Section 6 – Troubleshooting and Repairing
Section 7 – Administrative and Operational Tasks
Официальное руководство к экзамену с примерами тестов вы можете скачать по этой ссылке. В экзамене содержится 70 вопросов, а проходной бал, как и обычно, составляет 300. Записаться на сдачу можно по этой ссылке, стоит он $250. Официальные курсы по подготовке к экзамену доступны тут.
Ну и напомним, как сейчас выглядит путь сертификации инженеров VMware:
Теперь вот от компании Microsoft пришло официальное заявление о поддержке ОС Windows в качестве гостевых систем на архитектуре ARM, на базе которой и построены маки с процессорами M1/M2 (поддержка заявлена для разных платформ виртуализации, в том числе Parallels Desktop).
Для поддержки Windows на ARM-архитектуре VMware сделала такие нововведения, как работа с механизмом Fast Encryption и новым Virtual Trusted Platform Module, а также переработанный виртуальный сетевой адаптер и драйверы других устройств, над которыми ведется постоянная работа.
Также VMware работает с консорциумом ARM, Inc. для сертификации своих продуктов, и VMware Fusion 13 уже включена в программу cертификации Arm System Ready. Эта программа позволяет обеспечивать совместимость оборудования на физическом и виртуальном уровне для различного программного обеспечения, работающего на компьютерах с процессормами на базе ARM-архитектуры. Официальный документ по сертификации доступен тут.
Таким образом, как частные пользователи, так и крупные корпорации уже сейчас могут начать использование виртуальных машин с ОС Windows на компьютерах Mac, будучи уверенными в официальной поддержке такого варианта использования.
Многие пользователи применяют сценарии PowerCLI (недавно, кстати, вышла 13-я версия этого пакета) для автоматизации виртуальной инфраструктуры VMware vSphere на базе фреймворка PowerShell.
При этом для скриптов часто встает вопрос безопасного хранения данных учетных записей (логин-пароль), чтобы не указывать их прямым текстом в исходниках сценариев. Компонент PowerCLI credential store использует хранилище учетных записей, которое, в свою очередь, использует Windows data protection API для шифрования данных учетных записей и хранения их в файле. Поэтому PowerCLI credential store доступен только в Windows и не является кроссплатформенным. А что насчет пользователей Linux и MacOS?
Некоторое время назад Microsoft выпустила два полезных кроссплатформенных модуля SecretManagement и SecretStore (подробнее об этом тут). SecretManagement предоставляет командлеты, которые позволяют пользователям управлять паролями в различных хранилищах, а SecretStore - это, собственно, само хранилище и есть. Эти два модуля можно использовать вместо стандартного хранилища VICredential. Чтобы проиллюстрировать, как работать с ними, в VMware сделали пример модуля с разными версиями командлетов VICredential.
Первый шаг - это регистрация и конфигурация защищенного хранилища. В примере использования модуля, упомянутом выше, можно использовать Initialize-VISecret, который реализует эту процедуру - регистрирует SecretStore как хранилище по умолчанию и настраивает окружение так, чтобы пароль не запрашивался при доступе к хранилищу.
function Initialize-VISecret {
[CmdletBinding()]
param(
[string]$Vault = "VMwareSecretStore"
)
Этот режим по пользовательскому опыту близок к VICredentialStore, так как пароли хранятся в зашифрованном виде, но сам пароль при доступе к нему не запрашивается. В примере используется SecretStore по умолчанию, но можно изменить хранилище на любое по вашему выбору, а именно:
Чтобы сохранить креды в хранилище, нужно использовать командлет Set-Secret модуля SecretManagement. Сами креды в этом командлете идентифицируются по имени, но в примере ниже креды описываются двумя идентификаторами - имя пользователя и сервер, к которому нужно получить доступ. Такими образом, командлет New-VISecret склеивает строки "VISecret", сервер и имя пользователя в один идентификатор, который и используется для получения пароля.
Если вы хотите сохранить креды более чем для одного продукта, вы можете изменить функцию так, чтобы заменить VISecret на другую специфичную для продукта строку, чтобы создать идентификатор, например, "VMCSecret" для VMware Cloud. Можно передавать пароль простым текстом или в виде защищенной строки.
Также вы можете удалить креды из хранилища, используя командлет Remove-VISecret, который создает идентификатор и вызывает функцию Remove-Secret для удаления кредов. Если вы используете SecretStore в качестве хранилища, вы можете очистить его полностью с помощью функции Reset-SecretStore.
Создание нового идентификатора выглядит так:
function New-VISecret {
[CmdletBinding()]
[Alias("Set-VISecret")]
param (
[Parameter(Mandatory=$true)]
[string]$Server,
[Parameter(Mandatory=$true)]
[string]$User,
[string]$Password,
[securestring]$SecureStringPassword,
[string]$Vault
)
begin {
if ([string]::IsNullOrWhiteSpace($password) -and (-not $secureStringPassword)) {
Throw "Either Password or SecureStringPassword parameter needs to be specified"
}
if (-not [string]::IsNullOrWhiteSpace($password) -and $secureStringPassword) {
Throw "Password and SecureStringPassword parameters cannot be both specified at the same time"
}
}
process {
$params = @{
"Name" = "VISecret|"+$server+"|"+$User
}
if ($password) {
$params += @{"Secret" = $password}
} elseif ($secureStringPassword) {
$params += @{"SecureStringSecret" = $secureStringPassword}
} elseif ($Vault) {
$params += @{"Vault" = $Vault}
}
Set-Secret @params
}
}
Последний командлет в примере - это Connect-VIServerWithSecret. Он сочетает в себе оба командлета, приведенных выше, что дает интегрированный инструмент для работы по аналогии с командлетом Connect-VIServer для VICredentialStore. Вы можете вызвать Connect-VIServerWithSecret с логином и паролем, но использовать параметр -SaveCredentials для сохранения кредов в хранилище.
После этого вы можете опускать параметры учетной записи, а Connect-VIServerWithSecret будет автоматически получать пароль из хранилища и соединяться с сервером vCenter. При использовании VICredentialStore, если у вас сохранены креды только к одному серверу, вы можете соединяться с ним через Connect-VIServer без указания имени пользователя. А для использования функции Get-Secret параметр -Username является обязательным, так как не проверяется, что в хранилище сохранена только одна учетная запись. Чтобы упростить жизнь в этом случае есть глобальная переменная $global:defaultUser, значение которой и будет использоваться в Connect-VIServerWithSecret.
Иногда при работе администратора с виртуальными машинами VMware vSphere происходит ошибка при работе с дескрипторными файлами дисков VMDK, которая проявляет себя следующим образом:
Диск ВМ показывается в Datastore Browser, но иконка для него отсутствует
При включении ВМ вы получаете ошибку " File not found"
Сам файл ВМ вида <имя ВМ>-flat.vmdk есть в директории с машиной, но файла <имя ВМ>.vmdk вы не видите
Сам файл <имя ВМ>.vmdk отсутствует, либо он есть, но его содержимое повреждено
Эти симптомы могут возникать по разным причинам, но суть их одна - дескрипторный файл ВМ поврежден или отсутствует. Ситуация поправима, если у вас есть основный диск с данными - <имя ВМ>-flat.vmdk, и он сохранился в целости.
В 2012 году мы писали о том, как быть, если у вас возникла проблема с дескрипторным файлом виртуальной машины в среде VMware vSphere. В целом, с тех времен ничего особо не поменялось. Процесс этот довольно простой и описан в KB 1002511, также он детально разобран в видео ниже:
Часть 1 - восстановление основного VMDK виртуальной машины
Перед выполнением операций ниже обязательно сохраните полную копию папки виртуальной машины, и только после этого проводите все описанные ниже операции. Если у вас есть резервная копия виртуальной машины, и ее восстановление вас устраивает - то лучше сделать эту операцию вместо описанной ниже процедуры исправления дисков, так как вероятность ошибиться в ней велика.
Если вкратце, то для восстановления вам нужно выполнить следующие шаги:
1. Соединяемся с хостом VMware ESXi по SSH как root. Либо операции можно проводить непосредственно в консоли DCUI.
2. Переходим в папку с ВМ и определяем геометрию основного диска VMDK с данными <имя ВМ>-flat.vmdk
Делается это командой:
# ls -l <имя диска>-flat.vmdk
На выходе мы получим размер диска в байтах. Вывод будет выглядеть примерно так:
-rw------- 1 root root 4294967296 Oct 11 12:30 vmdisk0-flat.vmdk
3. Теперь нужно пересоздать заголовочный файл VMDK (<имя ВМ>.vmdk), чтобы он соответствовал диску с данными, используя тот же размер диска, полученный на предыдущем шаге:
# vmkfstools -c 4294967296 -a lsilogic -d thin temp.vmdk
После этого переименовываем дескрипторный VMDK-файл созданного диска в тот файл, который нам нужен для исходного диска. Затем удаляем только что созданный пустой диск данных нового диска, который уже не нужен (temp-flat.vmdk).
Если у изначальной машины диск был не растущим по мере наполнения (thin disk), то последнюю строчку, выделенную красным, можно не добавлять.
Вы также можете поменять тип адаптера ddb.adapterType = lsilogic на ddb.adapterType = pvscsi, если вы использовали паравиртуализованный SCSI-контроллер для исходной ВМ.
Консистентность виртуальной машины можно проверить командой:
vmkfstools -e filename.vmdk
Если все в порядке, то в ответе команды вы получите вот такую строчку:
Disk chain is consistent.
Если же исправить ситуацию не получилось, то будет вот такой текст:
Disk chain is not consistent : The parent virtual disk has been modified since the child was created. The content ID of the parent virtual disk does not match the corresponding parent content ID in the child (18).
После этого можно запускать виртуальную машину, добавив ее повторно в окружение vSphere Client.
Часть 2 - исправление дескрипторов файлов снапшотов ВМ (delta-файлы)
Ситуация усложняется, когда у исходной виртуальной машины были снапшоты, тогда папка с ней выглядит следующим образом (красным выделены важные для нас в дальнейших шагах файлы):
drwxr-xr-x 1 root root 1400 Aug 16 09:39 .
drwxr-xr-t 1 root root 2520 Aug 16 09:32 ..
-rw------- 1 root root 32768 Aug 17 19:11 examplevm-000002-delta.vmdk
-rw------- 1 root root 32768 Aug 17 19:11 examplevm-000002.vmdk
-rw------- 1 root root 32768 Aug 16 14:39 examplevm-000001-delta.vmdk
-rw------- 1 root root 32768 Aug 16 14:39 examplevm-000001.vmdk
-rw------- 1 root root 16106127360 Aug 16 09:32 examplevm-flat.vmdk
-rw------- 1 root root 469 Aug 16 09:32 examplevm.vmdk
-rw------- 1 root root 18396 Aug 16 14:39 examplevm-Snapshot1.vmsn
-rw------- 1 root root 18396 Aug 17 19:11 examplevm-Snapshot2.vmsn
-rw------- 1 root root 397 Aug 16 09:39 examplevm.vmsn
-rwxr-xr-x 1 root root 1626 Aug 16 09:39 examplevm.vmx
-rw------- 1 root root 259 Aug 16 09:36 examplevm.vmxf
Основной порядок действий в этой ситуации приведен в KB 1026353, здесь же мы опишем его вкратце (кстати, напомним про необходимость сделать полный бэкап всех файлов ВМ перед любыми операциями):
1. Определяем нужные нам файлы
Итак, заголовочные файлы снапшотов ВМ хранятся в так называемых файлах типа vmfsSparse, они же работают в связке с так называемым delta extent file, который непосредственно содержит данные (выше это, например, examplevm-000001-delta.vmdk).
Таким образом, опираясь на пример выше, нам интересны заголовочные файлы снапшотов examplevm-000001.vmdk и examplevm-000002.vmdk. Помните также, что диски и их снапшоты могут находиться в разных папках на разных датасторах, поэтому сначала вам нужно понять, где и что у вас хранится. Если у вас есть сомнения касательно имен нужных вам файлов, вы можете заглянуть в лог-файл vmware.log, чтобы увидеть там нужные пути к датасторам.
2. Создаем новый дескриптор снапшота
Итак, представим теперь, что файл examplevm-000001.vmdk у нас поврежден или отсутствует. Создадим новый дескриптор снапшота из исходного заголовочного файла examplevm.vmdk простым его копированием:
# cp examplevm.vmdk examplevm-000001.vmdk
3. Меняем указатели на файл с данными для снапшота
Теперь нужно открыть созданный файл в текстовом редакторе и начать его исправлять. Пусть он выглядит вот так:
# Disk DescriptorFile
version=1
encoding="UTF-8" CID=19741890
parentCID=ffffffff
createType="vmfs"
Красным мы выделили то, что будем в этом файле изменять, а синим - то, что будем удалять.
С данным файлом нужно сделать следующие манипуляции:
Строчку CID=19741890 заменяем на случайное восьмизначное значение (это идентификатор диска)
Строчку parentCID=ffffffff заменяем на parentCID=19741890 (идентификатор родительского диска, им может быть не только родительский основной диск, но и родительский снапшот, то есть его дескриптор)
Строчку createType="vmfs" заменяем на createType="vmfsSparse"
Строчку RW 31457280 VMFS "examplevm-flat.vmdk" заменяем на RW 31457280 VMFSSPARSE "examplevm-000001-delta.vmdk" (обратите внимание, что номер 31457280 остается тем же - он должен быть тем же самым для всей цепочки дочерних дисков)
4. Добавляем данные специфичные для снапшота
Теперь нам надо добавить в указатель снапшота кое-что новое:
Под строчкой createType="vmfsSparse" добавляем строчку
parentFileNameHint="examplevm.vmdk"
Ну и теперь надо убрать лишнее. Удаляем из файла следующие строчки, которые нужны только для основного родительского диска:
После этого вы можете попробовать запустить машину с дочерним снапшотом. Но перед этим также проверьте интеграцию дескриптора командой:
vmkfstools -e filename.vmdk
Ну и помните, что все эти действия по цепочке вы можете провернуть для следующих уровней дочерних снапшотов, если их диски с данными в порядке. Главное - не забывайте делать резервные копии перед любыми операциями!